Why misunderstanding object orientation sucks

Objection 1 - Data structure and functions should not be bound together

…

• Functions do things. …
• Data structures just are. …

Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.

Every good zoo-keeper knows that in a cage two fundamentally different types of thing must be kept together. If we want a system that's worth looking at and examining it must have animals doing things and vegetation for the animals to interact with, to eat and to process.

There is value in studying the two separately, but to actually understand any ecosystem we must study and understand the two together. The reductionist view of taking each separately only gets us so far before we start to miss things.

But of course we're not normally talking about studying ecosystems found in the wild. As software developers we have to build our own. To design a functional ecosystem that is going to be self-sustaining we must understand the animals and the vegetation together. We must understand how the vegetation grows, how the animals process it and how the animals interact with each other.

As systems get larger and more complex then the reductionist view becomes less and less relevant. It continues to have useful inputs into the design, but the development process itself must become more holistic in outlook or it will fail to produce a harmonious whole.

We find that we need better tools to help us understand and control how the system evolves. Object orientation is one such tool, but we should never be dogmatic about our tools. The important thing is to end up with a working ecosystem, not the tools we used to make it.

Objection 2 - Everything has to be an object

[Examples of time/date structures elided] Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system. There are no associated methods.

There are no methods in the example, but this is a semantic trick. There would have to be many functions within the system for manipulating these structures. If you don't wish to think of these functions as bound together in an object, then think of the class as a convenient namespace for grouping these functions.

As for everything being an object, this is only partly true. To make this statement true we have to group together two varieties of object—those with identity and those which are values. Many object oriented languages do in fact conflate these two types of data structure, but of course many do not.

This difference between object and value semantics is as fundemental to understanding object oriented design and programming as that of function composition is to functional programming. It is unfortunate that it is generally rather badly taught.

The example of dates and times given clearly needs to follow value semantics as a given date instance has no identity other than the value that it stores. Object orientated languages that don't allow this important point to be expressed do indeed suck, but that's a criticism of those languages—their implementation and design—not of object orientation itself which does recognise the distinction.

Objection 3 - In an [object oriented programming language] data type definitions are spread out all over the place.

Foyles in London is one of the biggest bookshops in the world. It is also a very old bookshop and until very recently stuck to some pretty quaint ways of arranging itself. All of the books were grouped by publisher. You could go to the Penguin section or the Doubleday section. The Cambridge University Press was separate to the Oxford University Press.

The store had pretty much any book that you may want to buy, but finding the book was almost impossible.

Most bookshops aren't like that, but even they tend to arrange their fiction and non-fiction differently. Non-fiction books are ordered by subject matter whereas fiction is ordered by author. Some bookshops will put all of the fiction together, but it seems to me that grouping them by type has become very popular (and useful), but on a given shelf they are always ordered by author.

This helps us to find the books that we want, but of course there is nothing inherently natural about the ordering of the books. We can think of other orderings and of course there are several other competing ways of ordering books which may be more useful for some purposes.

The organisation of the source code that we work with is similar in that it is governed by expectation, convention and personal preference. If we find that one person prefers to have their data structures defined together and the code that manipulates them somewhere else then we should also expect to be able to find somebody who prefers them together.

To argue about which is best and to try to argue that there is “one true way” is misguided. Most of us know to let people get on with whatever works for them.

Some object oriented languages do indeed make the choice for us about how to group the data definition and the code definitions (Smalltalk for example), but many allow us to define them together or separately as the whim takes us (C++ for example).

Objection 4 - Objects have private state.

State is the root of all evil. In particular functions with side effects should be avoided.

… The “hide the state from the programmer” option chosen by [object oriented programming languages] is the worse [sic] possible choice. Instead of revealing the state and trying to find ways to minimise the nuisance of state, they hide it away.

This isn't entirely true. Many object oriented languages do indeed force all state to be private, but it isn't the case that all do this. Private state is however an ideal much espoused within object oriented circles (as it were), but it is the implementation of the storage of the state that is meant to be private, not the state itself.

If we could build systems that didn't need to bother with state our jobs would be much easier, but the resulting software would be much less useful and interesting.

State must be handled and managed and object orientation provides a set of tools for managing this state. It provides tools for decoupling the different state required by different parts of a system allowing us to divide and conquer the complexity introduced by state.

If the power of monads is to allow the programmer to program as if state doesn't exist, then the power of object orientation is to provide tools to manage the state that the programmer must address. These two ways of managing state are complementary, not at odds.

Why OO was popular?

• Reason 1 - It was thought to be easy to learn.
• Reason 2 - It was thought to make code reuse easier.
• Reason 3 - It was hyped.
• Reason 4 - It created a new software industry.

I see no evidence of 1 and 2. Reasons seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind [object oriented programming].

I find this last part gobsmacking. A global conspiracy? A secret cabal of manipulators who tricked the world into using object orientation? Parsimony suggests a quite different explanation.

Further reading

• The three pillars of Object Orientation—An explanation of the fundamentals of object orientation.
• Encapsulation is a Good Thing™—A more reasonable explanation for why object orientation becames so popular.
• Object orientation—Other articles on this site about object orientation.

Daniel Lyons has written a response to this, Why Misunderstanding Concurrency-Oriented Programming Sucks