Object-Oriented Programming (OOP)

Imagine you are asked to write a program that keeps track of books, borrowers, and due dates at a small lending library. Where do you begin? 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?

This article follows one idea through the library scenario. You will see a program built around tasks, then the same problem built around objects, then trace how a single object's information changes as its behaviours run.

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, meaning the ordered steps that get something done. This is a task-centred design.

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.

The left column shows the task-centred shape: the program is a chain of steps, and the logic for each step sits in the procedure that performs it. The right column shows the object-centred shape: the program is a set of entities, and each entity is responsible for the information it holds and the things it can do. The same library problem produces two different program structures depending on which question you started with.

The definition names three things, and each one is a part of what an object provides. Behaviours are the things the object can do. Information is the store of data the object holds. Interactions are the ways the object works with other objects. Information and behaviours belong inside the object; interactions describe how it connects to what lies outside it.

The entity an object stands for does not have to be something you can touch. 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. A reservation or a rule about overdue fines can also be treated as objects, because they carry information and take part in behaviour. The question to ask is whether the thing matters to the problem and can be described by what it knows and what it does.

Now watch what happens inside one object over time. The information a Book object holds is not fixed. Calling one of its behaviours can change what it stores. The example below is an original illustration written for this article, applying the three properties of an object to the library scenario.

Notice that the Book is responsible for its own status. Whatever part of the program asks for a check-out only needs to trigger the behaviour; the object decides how its information changes.

Designing well means identifying the entities first, then deciding what each one holds, what each one can do, and how the objects work together. For the library, a reasonable set of entities is a Library, Book, Borrower, and Loan. The Loan is the abstract entity: it is the arrangement that connects a borrower to a book and carries a due date.

Read the diagram as a map of responsibilities. The Library contains many Book objects. Each Borrower can have many Loan objects. Each Loan concerns exactly one Book and carries its own due date. No single procedure has to know everything: each object holds the information relevant to it and connects to the others through its interactions.

Notice that the due date belongs to the Loan, not to the Book. The source's guidance is that a program should model what matters to the problem. In this model, a due date matters to the arrangement of a particular loan, so it is stored there.

When a task-centred mindset is carried into an object-oriented design, a recognisable pattern appears. One central procedure reaches into shared data and changes it directly. The diagram contrasts that shape with one where each object manages its own information.

When one object needs something done, it interacts with another object. In the library model, a Borrower wanting to take out a book does not edit the Book's status directly; it works through the objects' own behaviours. Interactions are the connections between objects, and they are what let a set of separate entities collectively solve the problem.