Attributes and Behaviors of Objects

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

In a task-first design, the program is a single sequence that moves through the work from beginning to end. Its shape is a line of steps, with each step depending on the one before it. In an object-first design, the work is distributed across several objects, and each one is responsible for its own part of the information and behavior. The overall program then emerges from how those objects interact rather than from one long ordered list.

The diagram is a picture of structure rather than a list of steps. In the object-first column, the items are things that exist in the lending library, and the program is described by which objects exist and how they relate. The task-first column is still a valid way to think, but it describes what the computer does in order, not what the library contains.

An object holds information about itself. A book object might remember its title, its author, and whether it is currently on loan. Suppose we start with a book that is available on the shelf. Its on-loan attribute says no. When the book is asked to mark itself as borrowed, its state changes, and the on-loan attribute now says yes. The title and author are unchanged, because the behavior only affected the part of the information concerned with availability.

Notice the direction of the change. The behavior is the thing that moves the object from one state to another, and the information stored in the object is what records the new state. A reader of the program can see the book's attributes and the behavior that changes them, without needing to follow a long list of steps.

The clearest way to see the object view at work is to follow a single event through the system. Here we trace what happens when a member borrows a book. The question to keep in mind is which object is responsible for each part of the work, and which object sends each request to which.

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 more 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.