6 The object-oriented approach

6.1 Modularity and the object-oriented approach

In the previous sections we discussed software development processes and the role of modelling. In this section you will meet the main object concepts. Object-oriented programming preceded object-oriented development by many years, and it is where the object concepts originate. Once we have explained these concepts, we shall revisit software development and modelling in object terms.

One of the great successes of software engineering over the past 50 years has been the introduction of modularity in programming languages. The idea of breaking a sequential program into named pieces was developed in the late 1940s. Eventually whole design methods came to be based on structuring large pieces of software around their intended actions. Each action was broken into smaller actions, repeatedly, down to unit small enough to understand, write and test independently.

One advantage of structuring software around its basic actions is that it gives good traceability from the actions to the code. In a payroll system, the code associated with end-of-year reporting will be in a module with that name. Within that module, the code associated with the action of printing a report heading will be in a procedure with a name related to printing headings.

It is less easy to do the reverse. If, say, a system needs to be changed so that every time a date is printed it is shown with four digits for the year instead of two, there is no easy way to locate all the relevant bits of code, and, once they are located, thousands of lines may need to be modified.

It has been observed that as businesses change, the things their computer system manipulate stay fairly stable, although the ways they are used change rapidly.

Commercial systems will always need to represent taxes, goods, payments, prices and deliveries, even though the business rules determining who is creditworthy, how orders are taken, and whether payment is required before delivery may all change frequently.

This observation led to a desire to structure software around the things that were manipulated, rather than around the actions that manipulated them. There might be one unit of software that handled all operations on a ledger, another that did everything for payment, and another for an order. If a business were to change the way it works, it would probably still need these units but the way they are coupled would change. There might be greater reuse of software in other projects. All commercial projects include customers and ledgers, so these components may be reusable without change.

An object-oriented system is a software system whose basic structuring is around things rather than around actions.