Designing a Program Around Entities

Suppose you are asked to write a program that keeps track of books, borrowers, and due dates at a small lending library. Where do you start? Many people's first instinct is to think about what the program must do: check a book out, record a return, send a reminder. That instinct is not wrong, but it points you toward one particular style of design.

Object-oriented programming, usually abbreviated OOP, starts from a different question: what are the things in this problem, and how do they relate to one another? The aim is to build a program whose structure looks like the situation it describes, so that the code reads the way people already think about the world. In this article you will see what changes when you begin with the things rather than with the jobs, and how to recognise the mistakes that come from skipping that step.

In older styles of programming, the work begins by identifying a computing task that solves the problem. The programmer then looks for a sequence of instructions that accomplishes that task. The program is organised around the procedure, the ordered steps that get something done.

Object-oriented programming reverses the emphasis. Instead of centring the design on tasks, it centres the design on objects. Designing the program means deciding which objects are needed and how they should work together, so that the set of objects as a whole models the problem at hand. Once the objects are in place, the tasks tend to show up as things the objects do, rather than as the starting point of the design.

Notice what the left column is doing: it is a list of jobs, and the design is shaped by the order in which those jobs happen. The right column is a list of entities. The jobs have not disappeared; they will reappear as behaviors of these entities. The difference is where the design starts.

An object is an entity that has behaviors, holds information, and can interact with other objects. Those three properties are the whole checklist. When you design an object, you decide what it holds, what it can do, and how it works with the other objects around it.

The three parts depend on each other. An object's behaviors usually read or change its own information, and its interactions are how it gets information it does not hold itself. A book cannot record its own return without the borrower's record also being updated, so the book and the borrower must interact. Designing well means identifying the entities first, then deciding what each one holds, what each one can do, and how the objects work together.

Now trace what happens when a borrower takes a book home. In an object-centred design, no single procedure controls the whole job. Instead, the objects involved send requests to one another, and each object does the part of the work that belongs to it. The diagram below shows the order of those requests for a checkout in the library scenario. This example is original to this article and applies the three properties of an object to the library problem.

Software objects can represent real entities, such as a physical book, or abstract entities, such as a due date, as long as they matter to the problem. The entity does not have to be something you can touch. A reservation, a due date, or a rule about overdue fines can be an abstract entity that a program still treats as an object, because it carries information and takes part in behavior.

The question to ask about any candidate is whether the thing matters to the problem and can be described by what it knows and what it does. A book matters to a lending library and knows its own status. A due date matters because the library cares when items are due, and it knows a date and can report whether that date has passed. A passing comment about the weather in the library's opening hours probably does not matter, so it does not need to become an object.