7.2 Programming with objects
To represent real-world objects such as an account or a payment in software we construct units of code, called objects, which assemble both data and operations that can act on those data.
Note: this concept is in turn an evolution of the idea of programming with abstract data types (Liskov and Zilles, 1974), which developed in the 1970s.
For instance, an object representing a bank account in software may include both a variable holding the account’s current balance and a number of operations for credit and debit transactions. Moreover, we expect that only those operations can access the data directly: other software wanting to affect the current balance would have to make use of those operations via an established interface. This particular feature of an object is called encapsulation.
What do you think the advantages of encapsulation might be?
Encapsulation provides an explicit boundary separating information about which operations are available and information on how such operations are implemented. In our example, outside the account object, available operations are advertised via their interface only, which indicates how they can be invoked. The implementation of the operations, i.e. how they materially access and modify data, and how the data are represented through variables, are not visible outside the object. In this way, as long as the interface remains unchanged, the operation implementation or the data representation can be modified without affecting other software.
In most programming languages an object is defined as an instance of a homogeneous class, with the class providing an abstraction for the common characteristics of all its instances. For example, a class-defining current-account object might indicate that each account will have a distinguishing account number and a balance, and that money can be withdrawn or deposited; on the other hand, each of its instances will have its own distinct account number and balance reflecting how much money is in the corresponding account.
What do you think the advantages of distinguishing classes and objects might be?
Classes allow for more succinct code and foster code reuse and flexibility. By defining a class we are defining the properties and behaviour of all the objects of that class that are created during software operation; when a change is needed, only the class code needs to change, with such changes automatically propagated to all its instances.
No serious software system consists of a single object. Instead there will be a collection of objects which collaborate to achieve the functionality of the whole system. Collaboration occurs when one object requests a service from another object in order to perform some task. To fulfil a particular collaboration, each object takes on a different role: the object that makes the request can be seen as the client, and the object that receives the request (and provides the service in response) as the supplier. The request is communicated to the supplier from the client by message passing based on the objects’ interfaces: the client sends a message to the supplier which on receipt executes a corresponding operation; when the supplier has completed the execution of its operation it returns a message answer to the client. Both the message and message answer may convey data between the objects, with the interface specifying the type of the arguments and the result of the operation.
Object collaboration through message passing is at the core of computation in an object-oriented software system, and many forms of collaboration can be forged between objects. In software development, a range of principles and techniques have been defined to design and implement object collaborations resulting in quality software.