DataslopeThe Birth of OOP
How Simula, Smalltalk, and Alan Kay's vision of "objects sending messages" reshaped software design
The software crisis demanded a new way of organizing code. The answer arrived in pieces, from a few people in a few labs, between roughly 1962 and 1980. By the end of that period, most of the ideas you will spend this course learning had already been invented — they just weren't yet mainstream.
This page is the story of how object-oriented programming was born.
Simula: classes for simulating the world (1962–1967)
In Oslo, Norway, two researchers — Ole-Johan Dahl and Kristen Nygaard — were trying to write simulations of complex real-world systems: ships in a harbor, customers in a queue, traffic at an intersection. They quickly noticed that the cleanest way to write such a program was to make the code mirror the world.
A ship in the simulation should be a thing in the code with its own
position, speed, and cargo. A customer should be a thing with their
own arrival time and patience. Operations on those things — arrive(),
depart(), loadCargo() — should belong to the thing they act on.
Out of that practical need came Simula 67, the first language to include what we now call classes and objects, along with inheritance and virtual methods. Long before anyone was philosophizing about software design, Simula was already organized this way because it was the obviously-correct way to write simulations.
Why this matters
Simula's central insight is the one we will return to in every chapter
of this course: the structure of your program should mirror the
structure of the problem. If the world has ships, your program
should have a Ship class. If a ship has cargo, your Ship class
should own its cargo. The closer that mirroring, the easier the
program is to understand and change.
Smalltalk and Alan Kay: "everything is an object" (1972–1980)
At Xerox PARC in California, Alan Kay and his colleagues Dan Ingalls and Adele Goldberg took Simula's idea and pushed it to its limit. They built Smalltalk, a language and an entire graphical environment in which everything is an object and the only thing programs do is send messages between objects.
In Smalltalk, even a number like 3 is an object. When you write
3 + 4, you are sending the message + 4 to the object 3. The
object decides how to respond. This may sound abstract, but it is
exactly the mental model we will use for Java in this course.
Kay later said he regretted the name object-oriented programming. He felt the important word was messaging, not objects. The objects are containers; the interesting behavior is in the messages they send to each other.
A program is a conversation between objects. Each one knows how to answer some questions and how to perform some actions. Nobody else reaches inside.
Let's see that conversation in Java. You will recognize the shape of the sequence diagram in the actual code.
The Order does not reach inside the Cart to add up prices. It
asks the cart for its total. The cart does not reach into each
Item to read its price field. It asks each item for its price.
Each object owns its own data and answers questions about it.
This is the most important idea in the whole course. If you internalize nothing else, internalize this: objects talk to each other by sending messages; they do not reach into each other.
A vocabulary that survived
By the late 1970s, the OOP community had settled on a vocabulary that is still in daily use today. You will meet each of these in detail later, but here is a one-line preview of each.
| Word | Meaning |
|---|---|
| Object | A bundle of state (data) and behavior (methods) that has identity |
| Class | The blueprint from which objects are created |
| Message | A request to an object to do something or answer a question |
| Method | The code an object runs when it receives a message |
| Encapsulation | Hiding internal state so the world can interact only through messages |
| Inheritance | Defining a new class as a refinement of an existing one |
| Polymorphism | Different objects responding to the same message in their own way |
| Abstraction | Working with what a thing does, not what it is internally |
A small modeling exercise
Before moving on, try to think in objects for a moment. Read this description, then look at the diagram and code that follow.
A vending machine has a tray of products. A customer inserts coins and selects a product. If they paid enough, the machine dispenses the product and gives change.
What are the things? What does each know? What does each do?
Three classes, each with a clear job. The customer does not reach into the machine's inventory. The machine does not reach into a coin's internals. Every interaction is a message.
Notice that:
VendingMachineowns itsinventoryandcredit. Nothing outside it can change those fields directly.- The only way to interact with the machine is by sending one of
its messages:
stock,insertCoins,select,takeChange. Productis its own object. Even the machine asksp.name()andp.priceCents()instead of poking at the product's fields.
That is OOP. The rest of this course is just elaboration.
Test your understanding
Who designed Smalltalk and championed the idea that "everything is an object" and "messages are the most important thing"?
Dennis Ritchie
John Backus
Alan Kay (with Dan Ingalls and Adele Goldberg at Xerox PARC)
Linus Torvalds
Simula 67 was originally designed for which purpose?
Writing the world's first operating system
Writing simulations of real-world systems (ships, queues, traffic)
Compiling Lisp programs faster
Replacing assembly language for microcontrollers
What does it mean to say that, in OOP, objects communicate via messages?
Objects literally send TCP packets to one another
Objects share a global mailbox where they leave notes
One object requests another to perform a behavior by calling one of its methods, and the receiver decides how to respond
Messages replace all uses of variables