If you ever sit down to wonder why object-oriented programming is the dominant paradigm in software design, you might have also wondered whether there were any alternatives. That is, not alternatives as in that which is theoretically possible (because there are many), but alternatives that offer the elegance of OOP in a pragmatic sense. The simple argument is that computer science, and thus programming, revolves around data structures, and an object is a natural way to think about data structures in an actionable way. We can build our applications by reasoning about the data that the application works with, and that trend lends itself well to things like objects where they seem to be a natural extension of the same idea.

While I am quite happy to leave it at that in describing OOP to novices, that explanation itself never suffices for me. The above explanation does not explain interfaces, abstract classes, and class hierarchies. The explanation leaves no room to think about proper design of interfaces, object relationships, and above-all, separation of concerns, which are all fundamental concepts in OOP.

In truth, I believe the answer lies in the fact that we’re not so attached to Objects as we are to Types. For example, if we take time to the most basic of expressions, like:

x * y

We might infer that we are working with integer or float types. In fact, this is basic type inference operating in the human brain. However, taking an expression like:

"Hello" * "World"

We might be much less inclined to give a proper explanation for what this might do. This is because we understand string types don’t naturally implement multiplication.

From the most basic examples like this, we come to understand that we don’t rely on values so much as we rely on behavorial contracts. Even at the most basic primitive types, we understand the types that implement ‘+’ and the types that implement ‘*’. Extending this to the higher level objects, we come across the most elegant way to describe our logic in programming statements.

By thinking about types, from the simplest Printers to design-pattern favorites like Factories, we can reason about our code in a way that lends itself well to implicit understanding. We can also reason about our code not necessarily from the point of view of the object (which is just an instance, just a “value”) but the interface for which that object implements. And because we reason about interfaces, we are really reasoning about complex types – a concept that is much more universal and broad than objects.

So really, when we talk about object-oriented programming, we’re basically presenting a misnomer for type-oriented programming, which is a much stronger and older concept than objects. While this explanation might seem trivial to those not necessarily curious about the details, to me, it helps classify and generalize concepts which may seem to be pure convenience (Objects) to concepts that are more universal (Types).

No tags