First of all. I admit that I am an OO junkie. I love designing objects and see them come to life in code. But as any professional I want to improve my skills and there are so many awesome things round DOD so I've set out on a mission to get some hands on experience with DOD by creating an data oriented, concurrent gameplay system. The goal is to learn and explore the pros and cons of such a system and how to implement it in an existing (OOD) code base. But more on that project in future blog posts. This post is about OOD and some common mistakes I've seen people do over the years. Naturally there are many more examples, but this post is thought to be a short interlude. What I find the best (and most fun/rewarding) to get to a nice design is to hijack a fellow programmer and harass him/her with my class diagrams getting feedback.
While reading about DOD, OOD often gets blamed for a lot of things. DOD evangelists seems to be determined that OOD systems are based around a generic base class with a crap ton of pure virtual functions (one which always is named update), enforcing multiple inheritance and creating bloated train wrecks of object dependencies?
The above is often very true. But as far as I'm concerned it's not due to OOD itself but to poor design!
One mistake programmers do with OOD is to think in terms of where to place code. Instead of creating simple classes that operate on a well defined group of data, a lot of effort is put to find common and preferably generic behaviors that can be applied to many different types of situations. This behavior is put in a class, labeled as a "base" class and inherited by other classes to "benefit" from the common logic. And since C++ allows for multiple inheritance we gladly inherit from multiple classes. Enter bloat and bad design as it creates objects that can take the shape of "virtually" anything ;). I like to visualize them as one-man-bands.
An approach I often prefer to inheritance is composition.
Let's say you want to create a a gameplay object that can be rendered and animated. Instead of inherit from some Mesh and Animation classes, simply make them members, i.e. instead of the gameplay object being a mesh and being an animated object, it has a mesh and it has an animated object.
Next stop is interfaces. I often hear the phrase "I want to make a nice clean interface". I agree. So do I, but an interface doesn't have to be virtual. Far too often OO programmers create a pure virtual interface to classes. Especially if the classes are considered a "system". The reason for doing so is often the desire to build in flexibility: "I want the flexibility to change the implementation in case we have to sometime in the future". The interesting thing is that often only one implementation of the interface exist, i.e. making the interface is completely useless and often the future doesn't arrive for those classes anyway...
Naturally there are times when you need an interface. But instead of just adding virtual everywhere I try to use NVI (http://altdevblogaday.com/41227102) where applicable.
Last but not least comes the desire of creating generic objects (which often leads to using virtual interfaces). Instead of creating one-man-bands I prefer to make x number of concrete classes instead. Compare the one-man-band to an orchestra where every member plays one instrument and do it well. Sure there will be some more code, but the code will be much cleaner, easier to maintain and less error prone as touching one class only have impact on a small area of functionality as opposed to big generic objects that could be used everywhere.
And that's all for this time. I hope you found it somewhat useful.
