Beyond Objects
This paper argues that the core object-oriented principle of mapping system functionality directly to problem-domain individuals is inherently flawed and leads to fragmentation, proposing instead to abandon object orientation in favor of an approach that decouples domain individuals from functional modules.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
The Big Idea: The "One-Size-Fits-All" Mistake
Imagine you are building a house. For the last 50 years, the standard rule in software construction has been: "Every room in the house must be managed by the person who lives there."
In the world of software, this is called Object-Oriented Programming (OOP). The idea is that if you have a "User" in the real world, you create a "User Object" in the code. That object is supposed to hold all the data about that user (their name, password) and do all the work related to them (logging in, writing reviews, booking tables).
Daniel Jackson argues that this rule is a trap. It sounds logical, but in practice, it forces software to become a tangled mess. He suggests we stop trying to cram every job into the "person" and instead organize software by what is happening (the actions), not who is doing it (the individuals).
The Problem: The "Swiss Army Knife" vs. The "Specialized Tool"
Jackson says that forcing every job onto a single "User Object" causes two main headaches:
1. The "Swiss Army Knife" Problem (Conflation)
Imagine a User Object is a Swiss Army Knife. It has a blade, a screwdriver, a corkscrew, and a toothpick.
- The Issue: If you want to use the corkscrew (to handle a user's password), you have to carry the whole heavy knife around. If you want to change the blade (fix a bug in the review system), you might accidentally break the corkscrew.
- In Software: A "User" object ends up holding the user's password, their review history, their notification settings, and their booking logic all in one giant file. If you want to change how reviews work, you have to dig through the code for passwords. It's messy and hard to fix.
2. The "Too Many Hands" Problem (Fragmentation)
Imagine a task like "Reserving a table."
- The Issue: Who should do it? The User? The Restaurant? The Table? The Reservation?
- In Software: Because the rule says "assign the job to the object," the code gets split up. The "User" checks if they have a booking. The "Restaurant" checks if the table is free. The "Reservation" object creates the ticket.
- The Result: To make a single reservation, the computer has to run three different people in three different rooms and have them talk to each other. If one person forgets to tell the other, the system breaks. This is called fragmentation.
The Analogy: The Restaurant Reservation
Jackson uses a restaurant to explain this.
The Old Way (Object-Oriented):
You have a "User" object and a "Restaurant" object.
- When Alice wants to book a table, she asks her "User" object.
- The User object asks the "Restaurant" object if a table is free.
- The Restaurant object asks the "Slot" object.
- The "Reservation" object is created.
- The Mess: If you want to change the rule so that "Alice can't book two tables at once," you have to update the User object, the Restaurant object, and the Reservation object. They are all tangled together.
The New Way (Concepts):
Instead of asking "Who owns this?" we ask "What is this group of rules about?"
Jackson proposes organizing software into Concepts. Think of a Concept as a specialized team or a department in a company, rather than a person.
- Concept 1: "Reserving"
- This team handles all the rules about making commitments. It doesn't care who the user is; it just cares about the act of reserving. It holds the list of who booked what.
- Concept 2: "Availability"
- This team handles the act of checking if a table is open. It doesn't care who is booking; it just cares about the slots.
- Concept 3: "User Authentication"
- This team just checks if the person is who they say they are.
How they work together:
Instead of the User object calling the Restaurant object, these "Concepts" talk to each other through Synchronizations (like a traffic light).
- Rule: "When a Request comes in, check if Availability says 'Yes', and if Authentication says 'Go', then Reserving can make the booking."
Why This is Better
- No Tangled Knots: The "Reserving" team doesn't need to know how to check a password. The "Authentication" team doesn't need to know how to check a table. They are separate.
- No "Who Owns This?" Arguments: You don't have to argue whether the "cancel" button belongs to the User or the Reservation. You just put the "cancel" logic in the Concept that manages the state of the reservation.
- Clearer Maps: If you look at the code, you see the business rules (Reserving, Availability) clearly, rather than a confusing map of who owns what data.
The "Concept" vs. The "Object"
- Object: A tiny machine that tries to be everything (Data + Logic + Identity). It's like a person trying to be a chef, a waiter, and a cashier all at once.
- Concept: A module that handles a specific job or relationship. It's like a specialized department. The "Chef Department" handles cooking; the "Waiter Department" handles serving. They coordinate, but they don't merge into one person.
The Conclusion
Jackson isn't saying we should throw away all software. He is saying that the core rule of Object-Oriented Programming—"Assign every job to the person it belongs to"—is the root of the problem.
By switching to Concepts, we stop trying to force the software to look like a collection of people. Instead, we organize it like a collection of rules and relationships. This makes the code easier to read, easier to fix, and less likely to break when you try to change one small thing.
It's a return to an older, simpler way of thinking (like relational databases) but updated for modern software needs, allowing us to build systems that are less fragile and more logical.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.