Designing Object Interactions

Imagine you have been asked to write a program that keeps track of books in a small lending library. Where do you begin? Many programmers learn first to ask what the computer has to do: look up a title, record a loan, print a report. Each answer becomes a step, and the program becomes a long chain of steps in a particular order. This is a workable way to think, and it is how many programs were structured before newer styles became popular.

Object-oriented programming, usually shortened to OOP, asks a different first question. Instead of starting with the actions the computer must perform, it starts with the things that exist in the problem: the books, the borrowers, the loans. In this article we trace what that shift means, how an object is defined, and how a set of objects can cooperate to get work done.

In a task-first design, the program is a single sequence that moves through the work from beginning to end. The designer lists the operations the computer must carry out and arranges them in order. The program's structure is therefore the structure of the work itself.

In an object-first design, the work is distributed across several objects. Each object is responsible for its own part of the information and its own behavior. The overall program then emerges from how those objects interact, rather than from one long list of steps. The diagram below compares the two shapes for the lending library. Notice that the object-first version is described as a set of things and the connections between them.

The first trait is information. An object remembers facts about itself. A book object might remember its title, its author, and whether it is currently on loan. These stored facts are the object's state.

The second trait is behavior. An object knows how to do certain things with its own information. The same book might be able to mark itself as borrowed or report its own due date. Behaviors are the operations the object offers to the rest of the program.

The third trait is interaction. Objects do not sit in isolation. A member object can ask a book object to become unavailable, and a checkout process can bring the two together. When designing one object, you should consider all three traits: what it remembers, what it can do, and which other objects it must work with.

Not every object in a program has to be a physical thing. A software object can stand for something you could touch, such as a book or a bicycle. It can also stand for something abstract, such as a loan agreement, a reservation, or a rule about how many books a member may hold at once. What matters is that the object corresponds to some entity in the problem domain, which is the area of the world the program is meant to describe.

Starting from the entities in a problem usually produces a design that is easier to understand, because a reader can look at the program and recognize the world it describes. The quality of the design still depends on choosing good objects, so the entities you pick and the way you divide responsibilities among them matter.

The clearest way to see the object view at work is to follow one event through the system. Here we trace what happens when a member borrows a book. Pay attention to which object is responsible for each part of the work. Before reading on, try predicting the answer to the question below.

Read the sequence from top to bottom and ask of each arrow: which object is doing the work, and which object holds the information it needs? In step 2, the checkout process asks the book to mark itself as borrowed. The change happens inside the book, because the book is the object that holds the on-loan information. In step 3, the book reports its due date using its own behavior. The checkout process does not need to know how due dates are computed; it only needs the book to answer.

This is the sense in which information and behavior are grouped together. An object bundles its own stored facts with the operations that act on those facts. When the operations live next to the data they change, the rest of the program can ask for a result without reaching in to rearrange the object's internals.

A borrow event changes the state of the objects involved. The table below records the book's stored information before and after the event, using the generated example of a copy of Dune. Only the on-loan information changes; the title and author stay the same.