Does the object-oriented paradigm deliver on its promises?


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.

Most computer science degrees will introduce students to OO concepts. Even programming languages that are not based on the paradigm tend to support OO development—-e.g. Scala, F#. The (arguably) biggest feature in the latest version of JavaScript is the addition of classes.

Seems like it’s difficult for us to conceive of developing large enterprises systems using any other model.

While object-oriented 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.

The three pillars of object-oriented programming

There are three main concepts, or “pillars”, in OO programming:

  • Inheritance
  • Polymorphism
  • Encapsulation

All three appear to be structurally unsound, but I’m going to focus on inheritance.

The failure of inheritance

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 books section 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”.

Dewey Decimal Classification and biological taxonomy are both real-world examples of categorical hierarchies and both are unwieldy systems used by specialists.

Folder management is another example. Sometimes I work on applications where the JavaScript files are in ./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:

  • bookcases containing books
  • cabinets containing drawers
  • draws containing files
  • files containing documents
  • computers containing components

Those are natural hierarchies—but they are containment hierarchies. Yes, I have a chair and desk. Both are furniture. However, that categorization is pretty abstract for my office design problems.

Inheritance hierarchies are also quite hard to get right. One of the tenets of SOLID OO software design is the Liskov substitution principle. It’s very easy to violate this without vigilance.

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 behavior.

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

  • title
  • location/size
  • look and feel
  • click handler

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 .NET Best Practices and Design Patterns.

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.