You can’t rule the development world for decades without attracting some enemies. And object-oriented programming, which provides the conceptual underpinning for dozens of languages old and new, certainly has some enemies.

Maybe that’s why we’ve suffered through a never-ending series of hot takes about OOP. They’ve described it as a productivity-destroying disaster, a set of deceitful programming patterns, and a mediocre tool designed to help poor programmers hide their incompetence. OOP was even proclaimed dead (14 years ago, so take that one with a grain of salt).

The four pillars of OOP

What all these rants have in common is that they point out (rightfully) some of the pitfalls in modern software design and then conclude (wrongfully) that this indicates a terrible rot at the core of the programming world. Yes, object-oriented programming doesn’t look so great if you conflate it with sloppy design practices and fuzzy architectural thinking. But are these crimes really an unavoidable part of OOP? Or are they just one of the wrong paths we sometimes wander as programming neophytes, armed with too much confidence and too much curiosity?

The Original Sin

The problems start with one brittle assumption made by some OOP supporters and almost all of its critics — that OOP is meant to model the real world. This is the original sin of OOP, a corrosive idea that’s responsible for countless bloated codebases.

Although there’s nothing in OOP theory that requires programming objects to parallel the real world, plenty of well-meaning teachers use this idea to lower the curve of complexity for new students. Here’s an illustration of the problem from Oracle’s official Java documentation:

“Objects are key to understanding object-oriented technology. Look around right now and you’ll find many examples of real-world objects: your dog, your desk, your television set, your bicycle … Software objects are conceptually similar to real-world objects.”

This is not an isolated example. Many introductory texts blur the line between code constructs and real-world objects, by presenting examples with Car and Wheel objects, or hopelessly tied-together groups of Person and Family objects. It’s madness.

This idea also leads to antipatterns, like exploding a database into a fog of linked classes with object-relational mapping.

This sort of design isn’t wrong for everyone. But there are plenty of unhappy people handcuffed to ORM systems, endlessly generating data class boilerplate that’s far less efficient than they want and for more complicated than they need. Did OOP encourage this? Maybe, but the real culprit is the idea-gone-wild that every identifiable thing deserves its own object representation.

Nothing good happens when we forget that our designs should be led by the needs of our code, not the completeness of our object models.

A better description of objects is — like many honest answers — a little vague. It goes something like this:

An object is a programming construct that lets you pack together data and functionality in a somewhat reusable package. Some objects may be structs by another name. Other objects may simply be libraries of related functionality. Deciding how to break down a programming problem into objects is part of the art of OOP.

And, from the always-insightful Eloquent JavaScript:

“The fact that something sounds like an object does not automatically mean that it should be an object in your program. Reflexively writing classes for every concept in your application tends to leave you with a collection of interconnected objects that each have their own internal, changing state. Such programs are often hard to understand and thus easy to break.”

An experienced programmer knows that when choosing between a solution that’s less object-oriented and one that’s more object-oriented, you should pick the simplest approach that meets the needs of your project.

#software-design #programming #oop #design-patterns #object-oriented