The Essence of OOP Is Messaging: Alan Kay’s Real OOP
When studying OOP, we always start by memorizing inheritance, encapsulation, and polymorphism.
Yet Alan Kay, who coined the term “object-oriented programming,” did not consider those three the core.
Here is the key point: the essence of real OOP, as Alan Kay described it, is messaging between objects, not the objects themselves. What objects exchange comes before how we divide classes.
By the end, you’ll understand why he even said he “regretted the name object-oriented,” and how this perspective changes our code.
Why Did Alan Kay Regret the Name “OOP”?
Alan Kay created Smalltalk at Xerox PARC in the 1970s. The term “object-oriented programming” came from him.
In 2003, when a developer asked him by email what OOP was, he replied:
“I regret having used the word ‘object.’
It caused people to focus on a less important idea. The really big idea is ‘messaging.’”
That sounds surprising at first. What we learned as OOP was always “how to design objects well.”
For Kay, the truly important part was not inside objects. It was the relationships and interactions formed as objects exchange messages—the essence of a system.
He compared programs to biological cells. Each cell hides its internals and communicates only through chemical signals, or messages. The internet works the same way: countless computers operate independently while exchanging only messages.
What Makes Message-Centered Thinking Different?
“Calling a method” and “sending a message” look similar, but the perspectives differ.
A method call is closer to “run this function on this object.” The sender must know something about the receiver’s internals.
A message is closer to “handle this; you decide how.” The sender wants only the result and need not know how the other side handles it.
Here is an example. The code delegates discount calculation to each membership-tier object as a “message.”
protocol Member {
func discountedPrice(for price: Int) -> Int
}
struct Gold: Member {
func discountedPrice(for price: Int) -> Int { price * 80 / 100 }
}
struct Silver: Member {
func discountedPrice(for price: Int) -> Int { price * 90 / 100 }
}
// The sender knows nothing about tier-specific calculation rules.
let members: [Member] = [Gold(), Silver()]
for m in members {
print(m.discountedPrice(for: 10000))
}
// Output: 8000
// Output: 9000The calling code contains neither an if statement nor tier names.
It sends only the message “calculate the discounted price”; each object owns the actual calculation. Even when a new tier is added, the caller needs no changes.
That is the power of messaging Kay described. The goal is not to split objects into tiny pieces, but a communication style that loosens coupling.
Then Are Encapsulation and Polymorphism Unnecessary?
No. Quite the opposite.
Take messaging seriously, and encapsulation and polymorphism follow naturally.
For objects to communicate only through messages, they must hide their internal state. That is encapsulation. Objects responding differently to the same message—that is polymorphism.
These concepts are not rules to memorize; they emerge naturally when you design around messages.
The problem is the order. Many people start with “let’s divide the classes properly.” You get plenty of objects, but they readily inspect one another’s internals, producing code that is object-oriented in name only.
Kay’s perspective reverses the order. First ask, “What messages should this object respond to?”
When Should You Use This Perspective, and When Should You Ease Off?
Message-centered design is not always the right answer. The important thing is to use it appropriately.
| Situation | Guidance |
|---|---|
| Domain logic with frequently changing requirements | A message-centered delegation structure is advantageous |
| Complex flows with many collaborating objects | Highly effective for reducing coupling |
| Simple data transformation or calculation scripts | Use functions instead of wrapping them in objects unnecessarily |
| Sections where performance is extremely critical | Excessive abstraction can become a burden |
In summary:
- The more collaboration and change a system involves, the more messaging pays off.
- For simple, fixed logic, it is better to keep things lightweight.
- Remember that the goal is not “dividing objects,” but “designing communication.”
This Is How It Comes Up in Interviews
Q. What is the essence of OOP according to Alan Kay?
Not objects themselves, but messages exchanged between objects. Kay compared objects to independently communicating cells and saw messaging as a bigger idea than inheritance or encapsulation.
Q. What practical benefits does message-centered design provide?
The caller need not know the other side’s internal implementation, which lowers coupling. As a result, adding a new type does not require changes to the caller, making the structure resilient to change.
If OOP feels difficult, before drawing a class diagram, ask yourself: “What are these objects saying to one another?”
Changing just one perspective can make your code feel much more solid. Wishing you good design today!