Goodbye, Object Oriented Programming
Charles Scalfani

Though thought provoking, I think the arguments largely fall down because of poor OO examples. Let’s start with inheritance. The first argument appears to be that having a deep hierarchy leads to more coupling with other objects (I asked for a banana and got a jungle). However, if all layers in the inheritance hierarchy have the ‘Is A” relationship then the links to all the other objects are required by the derived class so even if you collapsed all functionality into a single class you would still have the coupling. If the derived class does not require all the links to the other objects then this indicates that somewhere in the hierarchy the relationship is not strictly “Is A”. So the problem is not inheritance itself but a poor implementation of it.

There then seems to be confusion about using inheritance for containment. This is never a good idea and OO heuristics would recommend using delegation here. Again if there is not a clear “Is A” relationship between a derived class and its base class then don’t use inheritance. So in summary inheritance is valid and powerful but don’t misuse it.

The comments on encapsulation make a big deal about passing an object reference to a class constructor. I think there is confusion here between composition and association relationships. For composition I would expect the class to take over ownership of the object but it is also possible that the object reference is merely being used to set up an association. Encapsulation only applies to the composition relationship and even here it is legitimate to pass an object by reference if the receiving class clones the object or takes over ownership of it. The OO languages then allow the compiler to enforce access to all components.

Hence I think inheritance and encapsulation work fine within OO when correctly used.

Like what you read? Give Russell Creek a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.