When OOP Works and When It Doesn’t

A key problem with the OOP paradigm is its overuse, but how do you know when to use it and when to avoid it?

Conceptually, OOP is built on the idea of a network of independent objects communicating with each other. One object asks another object to do a serve for it. Often this way of looking at the world is preferable, especially at a large scale. It is how the internet works. We have individual severs communicating with each other and doing services for each other.

But there is a problem with this way of organizing programs at lower levels of granularity. The focus on objects with identity creates problems. If you are doing things with specific identifiable objects, then this leads you down a path where objects get mutated. It is harder to analyze code where objects change state a lot. Immutable objects are easier to reason about.

Thus in many cases we don’t want think of a specific object with a particular identity existing in a network of objects. Instead we want to think in terms of data-flow. Data flows through different pipelines and gets transformed. In this paradigm, objects are transient in nature. They come out of a processing node and disappear as they enter the next processing node. You can think of a Unix pipeline as an analogy. Functional programming and Data Oriented Design both work much more like this.

In this paradigm, there is not a natural push towards mutable objects. Objects are…