All the cool kids seem to be anti Object Orientated Programming (OOP) these days. “What is it good for?” You ask.”Absolutely nothing,” comes the reply. But, when I learnt programming it was sold to us as the solution to all our coding woes.
So, is OOP really that bad? Was it really a 35 year mistake? I don’t think so, although it definitely failed to live up to the original hype. Let me take you on a journey from hype to reality.
Let’s say we turned up to a class on OOP. The lecturer explains that OOP models the real world, because in the real world we have objects of different types or classes. And some object types have child-classes. So, we have animals, then we have fish, and mammals and reptiles. They’re all child-classes of animal. Under mammals you’ve got cats, dogs, and monkeys, etc.
Well, with OOP you can model all of this. The animal class has methods for all the things that animals do, and each child-class implements its own version.
So, for example, if the animal class has a makeNoise() method, then the cat’s version will meow, the dog will bark, horses neigh. And the your code over here can make all this happen without knowing anything about the particular animal. It just calls the makeNoise() method on all animal objects, and the correct behaviour occurs. The rest of your code is animal-agnostic.
This sounds awesome, so you decide to use this when making a game involving animals. You create classes for all the animals in your game. You’ve got labradors, huskies, dachshunds.
At first everything goes well. But then, you decided to add a dolphin, which is both a fish and a mammal, and you end up with the dreaded diamond class hierarchy
More cracks start forming. No matter how hard you try, your animal agnostic code over here starts having exceptions, where it really does need to know when something is a cat or a dog.
But you’re really smart. You can handle it, because you eat complexity for breakfast. You keep bouncing between the animal class and child-classes, as the animal class’s interface has to grow to meet the demands of more and more animal classes.
Eventually though, you add a DachshundWithRadio class, because it’s that kind of game it is, and something breaks. The number of classes is exploding. Things are getting out of hand. This sucks.
You step back, take a deep breath, and stare and think.
Then you realize your mistake. Object classes are an is-a relationship, but the dachshund has a radio. You’re trying to model a has-a relationship as if it were an is-a relationship. Oh, that’s why it isn’t working. Has-a relationships are better modeled by composing a larger object out of its components
So you start deleting classes like DachshundWithRadio, and reimplementing them using composition instead of child-classes. This is working better.
Next, you realize that a lot of what you implemented in code could be handled more efficiently if you stored specific traits in data tables, and wrote an interpreter instead of hard-coding everything. The project is now much more manageable.
Eventually, you delete most of the classes altogether, and have just a GameObject class that stores 3D meshes and materials, bones, sounds, and animations.
You still use child-classes for some things. For example, OpenGLRender and DirectXRenderer are both GraphicsRenderers. That works, because it’s a genuine is-a relationship. But, you keep class hierarchies shallow.
You’ve learnt that the grandiose promise of OOP was just hot-air, but that using it for constructors destructors and interfaces works great.
You lean back and admire your work. This is going great. The light is at the end of the tunnel.
Just then, you start seeing other programming techniques approaching. Each has their own sales-rep declaring that it’s the solution to all your programming troubles. But, you’re older and wiser now. So you ignore the hype, and evaluate each technique as a tool. What does it do well? What does it do poorly? What should you actually use it for? How is it best used?