6.2 Objects

To represent a thing such as an account or a payment from an object perspective, the software developers need to say how it can be used. An account is something that can be credited or debited with amounts of money and that remembers the total balance between operations. As users of an account, we do not care whether the balance is represented by electrons or by numbers on a slate, or whether the numbers are represented in binary or decimal. As long as we can withdraw money at some time after we have deposited it, it has all the behaviour of an account. An account must remember the current balance in some way, so it makes sense to talk about its state. Does it currently contain £100? How much would it have if we withdrew £27?

The usual way computers represent state is by storing values in variables. Behaviour is represented by operations of some sort. An object is a set of variables (data), with group of operations that can act on the data. But all programs contain operations and data, so what is the difference? The difference is the tight syntactic coupling between data and operations in an object-oriented language. In non-object systems, data tends to be globally accessible. Any part of a large program might access the main data store, such as a database or a data structure. There may be conventions and programming rules to suggest that accessing should be done in only a few places, but these are not enforceable. In an object system, the only operations that are allowed to access the data in an object are the operations attached to that object. Thus it is guaranteed that no other part of the system can touch the data.

To take a concrete example, think of how to represent dates. There are many candidate representations, such as:

• a string with a month name and a two-digit year; for example, 2 March 97;

• a string with slash-separated double-digit parts, with the month first; for example, 03/02/97;

• three integers, with the year in the range 0–99; for example, 2, 3, 99;

• an integer count of the number of days since 1 January 1901.

All these have advantages and disadvantages. Some are easier to print, others easier to parse, and others easier to compare to see which of two dates is the earlier.

If data is globally visible, a decision is usually made about the format, and that decision is published to the writers of every module that may need to use dates. Code is written according to the representation selected. For example, if the second representation is chosen, any code that needs the year will directly access the last two characters. Suppose it is necessary to change the format of dates, perhaps to speed up some operation that is done frequently, such as comparing, or to extend the range of representable dates. If the representation has been explicitly published, lots of code will depend on it, and changing it will be non-trivial. Every piece of code using a date will need to be altered.

If, instead, a date had been made into an object, no code outside the Date object could have manipulated the particular representation it used. All operations would be done by invoking operations of the Date object. When data are entirely hidden behind operations which alone can manipulate them, they are said to be encapsulated. Encapsulation is one of the central concepts of object-oriented technology.

Encapsulation provides an explicit boundary which separates information about which operations are available from information on how they are implemented. Outside the Date object, available operations are advertised via their signatures only (the signature of an operation is the specification of the type of the arguments and of the result of the operation); a signature specifies how an operation can be invoked. The implementation of the operations, i.e. how they access and modify data, is not visible outside the object. The visible operation signatures are said to be public while the encapsulated data and operation implementation are said to be private.

The operations provide all the information that anyone using a date would need. There is never a need to access the underlying representation of the date. If the representation needs to change, only the implementation of the operations on date need to be rewritten. All clients are totally unaffected, because they manipulate dates only through the operations provided. They need only to know the operation names – not their implementations – and the operation names stay the same whatever the representation.