MOBBLOC principles - the foundation of OOP

Where there are 2 programmers, there are 3 OOPs.

#Introduction

This article is the result of five years of research into Object-Oriented Programming (OOP). It proposes a set of principles called MOBBLOC as the foundation of object-oriented programming and rethinks modern views on OOP as a paradigm.

First, dear reader, I would like to ask you to answer one question before we continue: "What are the fundamental principles of OOP that distinguish it from other paradigms?"

Please take at least a minute to think about it, and then we will proceed.

You might have answered inheritance, polymorphism, encapsulation, and abstraction.

I will immediately say that these principles do not define OOP as a paradigm. While encapsulation and polymorphism can somewhat be considered basic principles of OOP (with some caveats), inheritance and abstraction are not suitable, and I will explain why further.

More importantly, among these four principles, there is no one that truly distinguishes OOP as a paradigm from functional programming (FP) and procedural programming.

Let’s first look at the widely accepted definitions of OOP to understand what is wrong with the modern conception of OOP as a paradigm.

The first definition that quite aligns with the generally accepted understanding of OOP:

Object-oriented programming (OOP) is a computer programming model that organizes software design around data, or objects, rather than functions and logic. An object can be defined as a data field that has unique attributes and behavior.

https://www.techtarget.com/searchapparchitecture/definition/object-oriented-programming-OOP

What conclusion can be drawn from this definition? Are objects at the core of OOP? But then, how does OOP differ from procedural or functional programming as paradigms?

Following this definition, it might seem that OOP is just a slightly more convenient way to organize code, nothing more.

But as we will see further, this is not the case — OOP is a completely unique paradigm, based on clear fundamental principles that may come as a revelation to you.

However, perhaps the main issue with OOP as a paradigm stems from this definition:

A language or technique is object-oriented if and only if it directly supports: [1] Abstraction – providing some form of classes and objects. [2] Inheritance – providing the ability to build new abstractions out of existing ones. [3] Run-time polymorphism – providing some form of run-time binding.

Why C++ is not just an Object-Oriented Programming Language, Bjarne Stroustrup (creator of C++)

It was C++ that became one of the first popular and widely adopted languages to implement OOP in its modern understanding — with classes and inheritance.

Undoubtedly, this was a step forward for the entire industry.

Thanks to OOP, C++ made code organization more convenient and more reusable. But in Stroustrup’s definition, two out of three points do not truly fall under OOP: abstraction and inheritance.

They do not distinguish OOP as a paradigm. It's likely that C++ was a turning point, where the shift in OOP and OOD went in the wrong direction.

Yes, an OOP language can have inheritance mechanisms, but the problem is that inheritance is not a fundamental principle of OOP as a paradigm. And the issue is not with C++ as a language — it has all the tools, and even more, to create an excellent OOP system.

The problem lies in the approach to OOP system design promoted by its creator, with abstraction and inheritance as its foundation.

Let's look at another definition of OOP. Perhaps it will help us understand what this paradigm actually is:

Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.

Object-Oriented Analysis and Design with Applications, Third Edition, Grady Booch

Grady Booch was one of the first to introduce inheritance, polymorphism, encapsulation, and abstraction as fundamental principles of OOP in his book Object-Oriented Analysis and Design with Applications.

Moreover, Grady Booch wrote the following about inheritance:

Specifically, programming without inheritance 'is distinctly not object-oriented; we call it programming with abstract data types.'

Attributing inheritance as an essential part of OOP is more of a tribute to the historical development of the paradigm and a popular simplified definition.

Modern practice shows that OOP can be effectively implemented without deep inheritance hierarchies, relying instead on interfaces, composition, and other mechanisms. Inheritance should be used cautiously due to its potential drawbacks.

Although it is worth giving credit, Grady Booch still describes in great detail the mechanism (although he does not classify it as a fundamental principle of OOP) that forms the true foundation of OOP:

From this perspective, an object is simply a tangible entity that exhibits some well-defined behavior. Objects do things, and we ask them to perform what they do by sending them messages.

And here is the real foundation of OOP:

I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging.'

And another one:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.

These two quotes belong to Alan Kay, the creator of the Smalltalk language and one of the pioneers of OOP.

It is this definition of OOP — centered around messaging and objects resembling biological cells or networked computers — that constitutes the original idea of OOP as a paradigm.

This will be explained in more detail later and formulated as a set of principles.

Nevertheless, it is worth noting that Alan Kay's principles will be used to formulate the foundation of OOP with some caveats and will be supplemented considering the evolution of OOP over more than 50 years.

The main issue with the widely accepted definitions of OOP is that they do not specify how objects interact with each other.

Popular definitions of OOP mainly focus on the internal structure of objects, which distracts us from the original idea of OOP — the core concept of this paradigm is built not around objects themselves, but around the interactions between them through messaging.

Let's clarify what is meant by "object" in this article. There are several implementations of OOP (which will be elaborated on later), and not all of them are based on classes that need to be instantiated (usually via the keyword 'new').

Therefore, the words "class" and "object" can be used interchangeably unless explicitly specified otherwise.

#What's wrong with OOP as a paradigm

Finally we shall place the Sun himself at the center of the Universe

Nicolaus Copernicus

In brief, the problem with OOP as a paradigm is that inheritance, polymorphism, encapsulation, and abstraction cannot fundamentally serve as the basis of OOP as a paradigm (except for encapsulation and polymorphism with some caveats).

If we follow these principles as the foundational elements of OOP, we might conclude that OOP is merely a somewhat more convenient way of organizing code, rather than a DIFFERENT PARADIGM.

Yes, OOP IS A DIFFERENT PARADIGM. A paradigm, from Greek, means "model." Another paradigm = another model. A flat Earth is one paradigm (model). A spherical Earth is a paradigm shift. Unfortunately, today, a paradigm shift has not yet occurred in OOP. But now, we will change that.

First, we need to start with how object-oriented programming (OOP) came about. It might seem that we don't need to know the history of computer science or OOP in particular. Just diving into the languages you use every day at work is enough, and everything will be fine.

However, if we want to deeply understand OOP as a paradigm, we should look back to the times of the bearded C programmers and learn why OOP was originally created.

Only then will we understand what problems OOP was designed to solve and whether it can help us address the challenges we face daily as programmers.

Now, let me ask you a second question: "What problems does OOP solve, and why is it needed? Is it possible that we don't need OOP at all and can manage with procedural or functional approaches?"

Just like with the first question, I ask you to think for a minute and answer before we continue.

Let's try to figure out what OOP is really for, starting with one of its earliest ancestors: Simula.

The first programming language that can be considered object-oriented in the modern sense was Simula (and it was this language that influenced Bjarne Stroustrup when creating C++, as well as the creators of Java, who acknowledge Simula's influence on their language).

Simula introduced concepts such as classes, inheritance, and dynamic binding for the first time.

But first, it's important to understand what problems the creators of Simula aimed to solve.

Ole-Johan Dahl and Kristen Nygaard set out to create a language that would allow modeling complex real-world systems in a convenient and structured way — such as the operation of machines on an assembly line, customer service in a bank, and so forth.

At that time, the popular language ALGOL was not quite suitable for this task. A more high-level language was needed. Consequently, in 1967, the general-purpose language Simula-67 was developed, laying the foundation for modern class-based OOP by introducing concepts like class, object, and inheritance.

Perhaps it was ahead of its time, which is why it did not gain widespread adoption among programmers initially. Additionally, it was quite inefficient in terms of resource consumption. Nevertheless, it inspired the creators of another revolutionary language — Smalltalk.

In the early 1970s, at the Xerox PARC research center, a team of scientists led by Alan Kay was working on the idea of a personal computer for everyone, including children.

Kay called it Dynabook — a portable device with a graphical interface, multimedia capabilities, and software. To realize this vision, a new, user-friendly, and powerful programming language was needed — thus began the story of Smalltalk.

The key milestone was Smalltalk-80, which became the first commercially available version of the language and environment, embodying Kay's philosophy.

As we have already learned above, here is what Alan Kay considered the main idea of OOP:

I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging.'

Less talk, more action. Let's see the full power and beauty of the Smalltalk language and messaging in a live example:

"creating initial string"
phrase := 'OOP is about objects'.

"Replacing 'objects' with 'messaging' with the message copyReplaceAll:with:"
newPhrase := phrase copyReplaceAll: 'objects' with: 'messaging'.

"Displaying the result with sending the show message to the object Transcript"
Transcript show: 'Before: ', phrase; cr.
Transcript show: 'After: ', newPhrase; cr.

Expressions ending with a colon, such as copyReplaceAll:, with:, show:, are messages, whereas phrase, newPhrase, and Transcript are objects.
Isn't it beautiful, flexible, and elegant?

In Smalltalk, everything is an object, and interaction between objects occurs through message passing.

Additionally, Smalltalk is one of the most concise languages in terms of syntax, fitting literally onto a postcard (don't get too deep into it—just scan through it):

exampleWithNumber: x
	|y|
	true & false not & (nil isNil) ifFalse: [self halt].
	y := self size + super size.
	#($a #a 'a' 1 1.0)
	do: [:each | Transcript
				show: (each class name);
				show: (each printString);
				show: ' '].
	^ x < y

Yes, this is the complete syntax of Smalltalk, and no, it's not a joke. We won't delve deeply into it, but still, Smalltalk deserves more attention than it currently receives.

Moreover, it reflects the original ideas of OOP as a paradigm—highlighting that its core is messaging between objects.

The main issues with modern OOP foundation — inheritance, polymorphism, encapsulation, abstraction — are:

• They do not define OOP as a paradigm but merely express a particular implementation of class-based OOP.
• They primarily describe the internal structure of objects, whereas the foundation of OOP as a paradigm is focused on external interaction between objects, which is what messaging is about.

The situation with OOP resembles the story of people's understanding of the shape of the Earth. Initially, Ptolemy, nearly 2000 years ago (around 150 AD), correctly knew that the Earth was a sphere and even measured its circumference with remarkable accuracy for the time — about 28,985 kilometers, only about 28% less than modern measurements.

Later, during the Middle Ages, people envisioned the Earth as a flat disk. It was only after the Middle Ages that humanity returned to the correct understanding of the Earth as a sphere.

The same story applies to OOP: in the 1970s, Alan Kay and his team at Xerox PARC developed Smalltalk, which embodied the fundamental idea of OOP as messaging.

Then, in the 1990s, C++ and Java emerged, steering OOP away from its original core (more precisely, the popularizers of OOP misunderstood that OOP is a different paradigm, not just a convenient way to organize procedures inside objects).

Today, it's time to revisit Alan Kay's ideas and rearticulate the fundamental principles of OOP as a paradigm.

As mentioned earlier, the problem isn't with languages like C++, Java, etc., per se, but with what their creators and other prominent authors promoted as the foundation of OOP.

#Why do we need OOP?

Initially, Object-Oriented Programming (OOP) was designed to simulate the real world (for example, conveyor systems, ticketing systems, etc.). Certainly, we cannot fully simulate real objects with OOP.

But, at least, it allows us to imitate the behaviors of objects that are necessary for our purposes.

Over time, it became clear that OOP is not only for modeling the real world. Creating games, enterprise systems, operating systems — these are not always directly related to real-world modeling, since objects in such systems often have no direct counterparts in reality.

Nevertheless, OOP continues to serve for system modeling, and it does so quite effectively. An important requirement for this is to make the system scalable.

Modeling a particular system can be implemented in almost any paradigm, but OOP particularly excels in solving a key task: creating low-coupled components.

Finally, after identifying the main challenges of OOP, exploring its history, and understanding the problems it addresses, it is time to formulate the MOBBLOC principles.

#MOBBLOC

Today, more than 60 years after the creation of Simula, over 50 years since Smalltalk was developed, and approximately 40 years after Erlang, we see a broader picture concerning OOP and can finally articulate its fundamental principles as a paradigm.

Yes, it’s similar to physics — the fact that an apple falls downward was obvious since the invention of the wheel, but the fundamental principles of physics have evolved and been rethought over time. Newtonian physics was replaced by Einstein’s relativity.

The same applies to astronomy: with the advent of more modern research methods, the notion of a flat Earth was replaced by the understanding of it as a sphere.

The history of OOP is no different — in 60 years, from Simula to today, we have tried many languages in production: Erlang, Java, Golang, and many others. It’s finally time to formulate the fundamental principles of OOP as a paradigm.

Let’s start with the first letter in the acronym MOBBLOC — M.

M — MESSAGING

Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.”

Steve Jobs on OOP in 1994: The Rolling Stone Interview

Even Steve Jobs understood the core idea of OOP correctly, despite not being a programmer. This idea is embedded in the quote above — messaging.

It is precisely messaging that distinguishes OOP as a paradigm.

Not inheritance.
Not encapsulation.
Not abstraction.
Not polymorphism.

Messaging is the most fundamental principle of OOP.

Everything else is merely an application of messaging.

The main feature that sets OOP apart from all other paradigms.

A mechanism without which everything else becomes meaningless.

The foundation without which OOP does not exist as a paradigm.

Messaging is sending requests from one object to another object to ask for a service.

In essence, there are two implementations of messaging — synchronous and asynchronous.

Asynchronous messaging involves the non-blocking transmission of messages between objects.
Examples include actor models in Erlang, Elixir, and Akka in Java/Scala.

An actor is an isolated, asynchronous entity that communicates only through messages and processes them one at a time.

Synchronous messaging – message passing between objects that occurs synchronously. Implementation examples: Java, C#, PHP, Go, Python, Swift, Smalltalk.

Calling a method in Java, C#, PHP, Python, etc., is considered an act of messaging, provided that we do not directly interfere with the internal behavior of the object and/or do not modify the object's state directly.

Let's consider the class Account and when calling its method cannot be regarded as an act of messaging:

class Account {
    public int balance;

    public void withdraw(int amount) {
        if (amount <= balance) {
            balance -= amount;
        }
    }
}

Account acc = new Account();
acc.withdraw(5);

Why is calling the withdraw method not considered an act of messaging? Because Account allows direct modification of balance, since it is a public field.
How to turn the call to withdraw into an act of messaging? Make balance private:

class Account {
    private int balance;

    public void withdraw(int amount) {
        if (amount <= balance) {
            balance -= amount;
        }
    }
}

Account acc = new Account();
acc.withdraw(7); // Now this is message passing, as we cannot modify balance directly

Additionally, messaging most closely reflects interactions between objects in the real world (although OOP is not always used for this purpose, for example in game development or enterprise applications).

If we return to the example above, we will understand that withdrawing money at a bank occurs through messages:

1. You arrive at the bank.
2. You ask a bank employee to withdraw $200 from your account (this is the message).
3. In response to this message, you receive a reply: either $200 is withdrawn, or the employee tells you that there are insufficient funds in your account.

At the same time, you are not at all interested in how exactly the money is withdrawn from the account: perhaps assistance from other bank departments is required.

Maybe the cashier needs to take money from another cash register. You are not concerned with what equipment is in the bank.

You are only interested in one thing: sending a message to the "bank" object and receiving a response from it.

Now the next three letters in MOBBLOC — OBB.

OBB — OBJECTS ARE BLACK BOXES

An object is similar to any electrical device, for example, a microwave oven. You interact with it only through buttons (public methods).

By pressing these buttons, you send messages to the microwave ("turn on," "turn off," "pause").

You are not allowed to disassemble the microwave or tamper with its wires (direct access to fields or internal methods is prohibited).

This protects the device from damage and keeps things simple for you.

The manufacturer of the microwave (the object developer) can repair and improve it internally without requiring you to understand all the details.

In general, the microwave functions as a black box for the user, with which we communicate by sending messages (through pressing buttons).

As mentioned above, messaging in OOP is impossible if an object is not a black box.

The "black box" principle in Object-Oriented Programming (OOP) is the idea that objects should hide their internal details.

Objects are black boxes — this principle states that objects should hide their internal implementation and prevent other objects from interfering with their internal state and behavior.

The principle of objects being black boxes (OBB) is essentially a form of encapsulation.

However, implementing the OBB principle alone does not make a language object-oriented. OBB or encapsulation are not exclusive to OOP, and without a messaging mechanism, a language cannot truly be considered object-oriented.

Yes, OBB is a fundamental principle of OOP, essential for implementing messaging. But it is a secondary principle that primarily facilitates messaging.

The term "objects are black boxes" was intentionally chosen instead of encapsulation because the MOBBLOC principles have a unique trait: they express abstract concepts through concrete entities.

MOBBLOC can be easily visualized as black boxes that communicate with each other through messages.

Moreover, this is a self-explanatory term.

If encapsulation needs to be explained, then the principle that objects are black boxes, along with messaging, will be understood by a first-grader.

Here's a simple example of why the principle "objects are black boxes" by itself cannot form the basis of OOP without messaging: closures in JavaScript can easily implement encapsulation:

function createCounter() {
    let count = 0; // Private data
    return {
        increment: () => count++
    };
}

But does createCounter() support message passing? No.

Therefore, the fundamental principles of OOP are messaging combined with black box objects.

In the end, the last three letters in MOBBLOC — LOC.

LOC — LOW COUPLING

Thus, the two basic principles of OOP are established.

Now, it's time to understand what problem OOP aims to solve.

This is hidden in the last three letters: MOBBLOC, specifically LOC — low coupling.

Yes, low-coupled modules can be created in any paradigm.

But OOP, with its mechanisms of messaging and black box objects, was specifically designed to model systems as objects that have low coupling between them.

OOP initially divides the modeled system into isolated entities called objects, and low coupling between these objects is the main goal of this paradigm.

Here is the reasoning process that leads us to the main goal of OOP:

• Objects are black boxes to each other and communicate via messages.
• This allows for creating low-coupled objects.
• Low coupling makes the system scalable.

The main goal of OOP is low coupling between objects, achieved through messaging and black box objects, which makes the system scalable.

A question may arise: why is high cohesion not included in OOP as a primary goal alongside low coupling?

The answer is as follows: at the paradigm level, OOP should focus on external interactions between objects, and low coupling is more related to these external interactions.

At the highest level in OOP, we are generally not concerned with the internal structure of objects, as they are considered black boxes by definition.

However, high cohesion is definitely very beneficial.

But at the current level of discussing OOP as a paradigm, this is not our main concern.

When we talk about specific implementations of OOP — whether class-based, prototype-based, actor-based, or others — then we start to worry about high cohesion.

In OOP terminology: MOBBLOC is a contract or interface, and how it is implemented in specific languages is the implementation of that contract.

At this stage, when we formulate OOP as a paradigm, we are not interested in what’s inside the object: it may contain code written in a functional style, procedural code, or even assembly inserts.

We are not concerned with how testable the object is at this point.

Right now, we are defining OOP as a paradigm.

It’s only during the implementation phase of this paradigm that we can and should think about high cohesion, testability of objects, and other details.

This is similar to the concept of the shape of the Earth: it is also a paradigm upon which everything else is built — how ships float, how airplanes fly, how we perceive the world.

At this level, we are not interested in the Earth's internal structure.
All we care about at this stage is the shape of the Earth.
A sphere?
A disk?
A cube?
And all other ideas are based on this fundamental concept.

The same applies to OOP.
Right now, we are examining it as a paradigm.
What is it?
Why do we need it?
What is an object?
Based on it, we build more concrete details about the internal structure of objects.

Let’s return to low coupling.
Thanks to low coupling, we get a scalable system.

By scalability, we mean the ability to extend the codebase — how difficult or easy it is to add new functionality over time.
It’s good if the main goal of OOP is measurable, and in the case of MOBBLOC, it indeed is.

In the case of class-based OOP, the following metrics are used to measure coupling:

• Efferent Coupling – the number of classes that the current class depends on
• Afferent Coupling – the number of classes that depend on the current class
• Coupling Between Objects – the number of classes that the analyzed class is directly connected to

There are more metrics for coupling. These three are presented here primarily to demonstrate that the main goal of OOP is measurable.

Let’s examine one of them in more detail.

Coupling Between Object Classes measures how many other classes interact with a specific class. Coupling occurs through:

• Method calls
• Variables within methods
• Class-typed properties/parameters
• Inheritance
• Method arguments/return types

While some coupling is necessary for functionality, excessive coupling complicates scalability.

Analysis of CBO:

• 0: 🚫 Class is isolated (probably shouldn't be in the system)
• 1–4: ✅ Ideal (loosely coupled, high scalability)

Thus, during the formulation of MOBBLOC, we clarified our stance on two of the four principles currently considered the pillars of OOP: encapsulation and inheritance. What about polymorphism?

Polymorphism is not a fundamental principle of OOP as a paradigm because objects are considered black boxes, and it doesn't matter what happens inside them.

The focus is on messaging — that is, on the interaction between objects.

Though polymorphism can be considered to be a part of messaging to some extent.

But it is an implementation detail of messaging, but not messaging itself.

Most importantly: knowing the main task that OOP handles well, you can answer the question: Should you use it in your project?

Perhaps you don’t need OOP for a one-time script of 150 lines that parses a list of products from a JSON file, where low coupling isn’t critical.

But for a banking system with 350,000 lines of code, OOP is ideally suited, as it involves modeling numerous entities — ranging from customer accounts to accounting and security — and maintaining low coupling among them.

Thus, we have formulated 2 fundamental principles of OOP and the main goal of OOP expressed as MOBBLOC:

• M — Messaging
• OBB — Objects are Black Boxes
• LOC — Low Coupling

In MOBBLOC, one principle follows from another:

• M – objects communicate via messaging
• OBB – for the interaction between objects to be called messaging, they must be black boxes
• LOC – the main goal of OOP as a paradigm is to ensure low coupling among system components, achieved through messaging and objects being black boxes

This is sufficient for writing OOP code.

The only principle among these three unique to OOP as a paradigm is messaging.

But if an object is not designed according to the OBB principle, its interaction with another object is unlikely to be considered messaging in terms of OOP.

OOP = (messaging + objects are black boxes) → low coupling

Advantages of MOBBLOC:

• They are easy to understand and apply—even a first-grader can grasp them
• They can be easily visualized as communicating black boxes
• They clearly define the core and main task of OOP as a paradigm

Now, it’s time to define OOP as a paradigm and outline the main concepts of OOP.

Object — an abstraction that has mechanisms for hiding its internal behavior and state, as well as mechanisms for sending and handling messages from other objects.

OOP — a programming paradigm whose fundamental goal is to ensure low coupling between objects, achieved by objects communicating via messages and being black boxes for each other.

Sources:

• https://www.researchgate.net/publication/49595557_Inheritance_Metrics_for_Object-Oriented_Design#:~:text=The%20inheritance%20metrics%20give%20us,super%20class%20and%20its%20subclass.
• Rajnish K. and Bhattacherjee V., “Class Cohesion and Development Time: A Study,” Proceedings of the National Conference on Methods and Models in Computing (NCM2C-2006), December 18–19, 2006, School of Computer and Systems Sciences, JNU, New Delhi, India, pp. 26-34. International Journal of Computer Science & Information Technology (IJCSIT), Vol 2, No 6, December 2010
• https://wiki.c2.com/?AlanKayOnMessaging
• https://objectscriptquality.com/docs/metrics/coupling-between-object-classes-cbo
• https://objectscriptquality.com/docs/metrics/lack-cohesion-methods-lcom4
• https://www.stroustrup.com/oopsla.pdf