The Object Oriented Programming [OOP] paradigm is often associated with many great programming concepts including polymorphism, encapsulation and composition to name a few. However, even with a little experience in a functional programming language like haskell for example, you would quickly realize that these techniques are not exclusive to OOP at all.
If that is the case, then what ideas does OOP bring forward that make it so well known and widely adopted in the industry?
To answer this question, we’ll take a look at the early discussions of Alan Kay, commonly recognized for having coined the term “Object Oriented Programming”.
Interestingly, many of the concepts Alan envisioned as being central to OOP are not found in most software projects and certainly not in any languages that claim to be object oriented today.
- OOP Was Inspired By Biology
- Inter-Object Communication
- Objects are Intelligent and Self Contained
- The Actor Model
OOP Was Inspired By Biology
Alan Kay’s notion of OOP was heavily influenced by his background in Biology. It’s initial conception was modeled around the functioning of biological cells in the human body:
“I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.”
Through this single model alone, Alan described a radically different understanding of OOP in comparison to today’s understanding of the concept. To illustrate this point further, Alan says,
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
This model differs with the mainstream understanding of OOP in two main areas: inter-module communication and the role of objects in a system.
Inter-Object Communication
Objects are commonly thought as central to the understanding of OOP, that’s probably why its called Object oriented programming - except its not. In fact, it is this idea that has caused many to misunderstand what is actually at the core of OOP:
“The key in making growable system has much more to do with how its modules communicate rather than what their internal properties are.”
Moreover, this communication between modules must take place through messaging.
“It’s not even about classes. I’m sorry that I long ago coined the term objects for this topic because it gets too many people focused on the lesser idea. The big idea is messaging.”
A method call was not the way modules in an OOP system
intended to communicate, rather it was through messaging - and yes, there is a significant difference between the two.
Communication in OOP should be thought as message passing, not method calls. Message passing results in smart objects that accomplish tasks together via content negotiation. Method calls result in many unintelligent objects that are constantly told how to do their job. #oop
— Muntazir Fadhel (@FadhelMuntazir) March 5, 2019
The difference is in the way we perceive method calls versus messages. Calling a method essentially puts the person making the method
call in control of running the process. The caller gets the callee to do something and prevents it from doing something that the caller
does not want. Message passing on the other hand revolves around negotiation, and this is the key in building object oriented systems.
Method calling vs content negotiation via message passing
Because of method calling, we’ve trained ourselves to develop systems where a single or group of classes are primarily responsible for controlling the software and getting things done. By thinking about communication between modules through messages, we are more likely to build systems composed of independent intelligent objects that communicate with each other to accomplish tasks - no single unit is responsible for running the show.
Objects are Intelligent and Self Contained
One of the main principles in object oriented systems today involves modeling objects after living things. And yet, most object oriented systems fail to achieve this goal in many ways.
Consider the code example reproduced below taken from a
tutorial on encapsulation
by a well known website on programming. This example is thought to demonstrate encapsulation because the age private field variables are not accessible
directly. Rather, external callers must access the field variable through a public method.
/* File name : EncapTest.java */
public class EncapTest {
private int age;
public int getAge() {
return age;
}
public void setAge( int newAge) {
age = newAge;
}
}
And yet, this is a poor example of encapsulation because this class can be torn apart by other objects. Anyone can read its internal data and inject new data into it through its setters.
Unfortunately, the prevalent use of getters and setters in “OOP” code is a result of a fundamental misunderstanding of real life objects.
That is to say, we often model objects as dumb, incapable, data-holding objects with methods. Our objects are usually not self contained, and rely on a large network of other objects and data to perform their function properly. However, Alan Kay envisioned objects to be intelligent, independent and self contained units - like computers on a network or the cells in our body.
They are living organisms, with their own behavior, properties and a life cycle. But most importantly, they are in control of their internals and they run their own show.
This idea immediately clashes with the way objects are designed in a modern object oriented system. Objects should prefer immutability. Rather than having their state changed at the will of any external force through getters and setters, objects should be self contained and hide internal data properly.
A living organism does not allow anyone from the outside to change its properties (they can request to do so however). Alan’s visions of objects also clashes with the idea of class inheritance. The use of inheritance results in dependent and by extension fragile objects that are highly coupled to their inheritance hierarchy. Again, this goes against the notion of having independent, self-contained objects.
There’s a great quote by Joe Armstrong, the creator of Erlang, that summarizes this problem:
“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
The Actor Model
To conclude, the implementation of the ideas behind messaging combined with the creation of self-contained, intelligent objects will give rise to truly OOP systems. Systems, that will actually demonstrate the information hiding mechanism promised by encapsulation.
If you would like to see a computational model that contains many of the ideas that Alan Kay envisioned in OOP, take a look at the Actor Model.
If you enjoyed this post, subscribe to my mailing list to be notified of future posts, and kindly share on Twitter .
