OOP is a tool
Apr 7th, 2008 by phil
I spotted this comment to a lengthy article about the proper use of inheritance in Object Oriented programming:
On one of the ‘communities,’ someone had a sarcastic response to the Final == Good article: To boil the article down: OOP is hard. Let’s make it as non-object-oriented as possible so that things don’t get too complicated!
I think that’s actually correct in a way. OOP actually is hard to get right. Encapsulation is not hard, it is a simplifying principle. But inheritance is seductively easy in the trivial case but hard to get just right in the wild. Thus, the admonition to favour composition.
That does’t mean we never use it of course. But I am not embarrassed to say that I think inheritance is hard to get right.
This strikes me as odd; the whole point of OOP is to make it easier for programmers to conceptualize and build complicated software systems. If inheritance is complicating the issue rather than simplifying it, maybe OOP needs a rethink.
The only “right” way to do OOP is the way that helps the programmer deliver high quality software in a reasonable amount of time. This isn’t something that strikes me as capable of being objectively right or wrong. I think that there is a danger in overthinking issues like this or in assigning too much value to being “object oriented.”
I think the difficulty lies in using the right amount of inheritance. There’s a fine line in the overuse of inheritance and getting the usage just right. The Final==Good article was an interesting find. Thanks Phil.
The root cause of problems faced with use of OO is that it is talked about as a lump when it really falls apart into multiple different techniques
While implementation inheritance tends to be the major focus of teaching, it tends to be the least useful (& most complicated) in practice (mix-ins or composition often being a simpler route to the same end).
@Steve: very insightful. I hadn’t thought of it like that, but you are right. OO isn’t really a monolithic thing, it is a set of practices with varying degrees of utility.
The key here is “high quality”. I think the manager example is pretty clear in this regard. I’d argue that a software were you can’t unit test a class properly is not high quality, even if it happens to be correct.
A high quality software necessarily has diminished maintenance costs, and lack of strong unit tests definitily increase the cost of maintenance severely.