I’m using Ogre3D, so I’m using several classes who inherits Ogre and OIS classes to make my project run.
I’m starting to have some problems, because I’m constantly in need to access variables from one singleton to tell it to another to do what I want, so I have this huge mass of getters/setters which bloat my project.
I know that keeping data at reach is important for performance, and OOP sort of encourages such practice by default since you keep variables you need inside your class, but at some point it feels like a huge constraint and I end up making some much initializations with all those constructors, it’s pathetic.
My little ridiculous game will never requires that much resource, Ogre3D use OOP so it can do its job efficiently, it doesn’t require me to use OOP to do my game.
I’m thinking about putting all my data into different struct to make everything public, and not care about encapsulation.
Will it have an impact on performance, despite its bad OOP design ?
If you want to improve your performance with caching, OOP is not a show stopper, but also not the perfect programming paradigm: It often suggests mutable states in your objects, e.g. setters, as you’ve mentioned, to simplify constructors. With mutable states, re-usability of the objects, and thus caching, becomes much more difficult. Therefore, try to minimize mutability (see e.g. Josh Bloch’s Effective Java, Item 15).
That’s why the functional paradigm is more suitable. But you can adopt it pretty well in classical OOP. Modern OOP languages (e.g. Scala, C#, C++11) are actually multi-paradigm and offer all features necessary for easy immutability and functional programming in general.