I’ve been programming using the object-oriented (OO) paradigm for most of my career. It’s the dominant paradigm in enterprise software development and has been for some time.
I’ve used, and use, other paradigms, such as functional programming, but, like most software developers, the bulk of my time as been spent using OO languages, such as C# and Java.
Seems like it’s difficult for us to conceive of developing large enterprises systems using any other model.
While OO programming has clearly been wildly successful in terms of market share, has it really delivered on its promises? Does it really make application development easier?
One of the challenges for such a question is that it’s difficult to adjust for the effects of education, training and experience. The majority of the developers no doubt find it easy to think of their applications in OO terms. However, they’ve had massive exposure to the concept by the time they are experienced developers.
I can just about remember getting into OO programming—and it wasn’t immediately intuitive.
There are three main concepts, or “pillars”, in OO programming
All three appear to be structurally unsound.
Inheritance is one of the most touted benefits of OO programming. It’s also the shakiest of the three pillars.
When presented, it feels quite intuitive. It’s effectively designing applications as a categorical hierarchy. Shopping catalogs are an example. There’s a books section. That contains a computer books section. In turn, the computer books section contains programming books…and so on.
However, categorical hierarchies suck as a design approach. Really. I never use such a hierarchy in shopping catalogs. If I’m interested in in the Angular web development framework, where would I find it? Under programming languages? Frameworks? Web development?
Who cares? I just search for “Angular”.
./scripts/accounts/ while in other applications they are in
./accounts/scripts/. Both work…which is part of the problem. It’s not a natural hierarchy—and one of the benefits of OO is that it’s supposed to map to the real world.
In fact, if you look around, there aren’t many obviously useful examples of nature inheritance hierarchies. Containment is far more common. As I look around my office I have
Those are natural hierarchies—but they are containment hierarchies. Yes, I have a chair and desk. Both are furniture. However, that categorisation is pretty abstract for my office design problems.
One of the classic toy examples of inheritance used in teaching (many of them seem to be “toy” examples) is geometric shapes. A square is a type of rectangle that has equal sides. However, this hierarchy can violate our Liskov substitution principle. When we set the width and height of a rectangle to 2cm and 1cm, respectively, we expect to receive those same values back when we read those properties.
However, if our rectangle is a square, setting the width will change the height. So our calling code may now need to be aware of this potential behaviour.
One of the benefits often forwarded for inheritance is that it increases reusability. In my experience, however, inheritance hierarchies tend to be specific and brittle. Composition is a much easier way to reuse classes.
Joe Armstrong, the inventor of Erlang, has said
The problem with object-oriented languages is they’ve got all this implicit environment they carry around with them. You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle.
OO-based libraries often result in unhelpful levels of complexity. You’d think a button on a form would be pretty simple, right? Probably needs not much more than
Above is a list of the properties exposed by a simple Windows Forms button in Visual Studio…the pop-up window isn’t big enough for us to have reached the properties that start with “B”! That’s pretty complex for a simple button.
So, inheritance looks pretty shaky from a number of directions. Consideration of polymorphism and encapsulation will have to wait for a future article.
If you are interested in software design and best practices you may wish to attend the following Learning Tree course