I think for enterprise type software OOP works well. It easily allows us to re-use code and solve common problems once in a parent class and have that solution

I think for enterprise type software OOP works well. It easily allows us to re-use code and solve common problems once in a parent class and have that solution easily propagated to child classes. However, when developing a video game, I ran into quite a few OO design conundrums that IMO were the hardest programming problems to solve in my career. I started looking into data driven design, and while I never changed my code to implement it, it looked like it might have been easier for the video game. I do not know for sure. But I do know that getting OO right in the video game I was implementing was daunting. Maybe I was doing it wrong. The one issue we kept running into was how to design it so that the flow of dependencies flowed in one direction. That is to say, classes should not require references to classes that were higher up the food chain, and vice versa. It sucked when you realize that your Bullet class requires a reference to the BattleField class when the BattleField object was not being passed down through all the intermediate objects that separated the two. I would be willing to say that it could have been poor design, or rather not realizing that dependency earlier in the process to deal with it. But many things we did not know till the requirement or change came up. Then it was programming somersaults to deal with it. Eventually we did get better at re-arranging things as things came up, basically we got used to having to change a lot of the design at a drop of a dime. I do not know if data driven design would have helped, but it did sound like it was worth a shot. I must admit though, I do remember a data driven program i worked on, and it bothered me how much data had to be passed around that was not relevant to the method/class that was using it. And a lot of data got lumped together out of convenience.