Pattern 4.1 The Immutable pattern
As mentioned in the Introduction, an emerging trend in software development is to capture tried and tested solutions to recurring problems as "[link url=/od/oopindelphi/a/aa010201a.htm]patterns[link]". Patterns are often described quite formally under a number of set headings to make it easy for experienced pattern users to understand a new pattern. Here we use a less formal approach since this is an introduction to the concept.We’ll first describe the general context that applies to the pattern, what the actual problem is, and the factors to take into account when solving the problem. Then we’ll describe a solution to this problem, indicating its strengths, restrictions and weaknesses. At the end of the chapter we’ll give references to the initiator of the pattern and possibly to some other sources of information about it.
The need to create an object that can’t be changed later is a recurring problem that has been formulated as the Immutable pattern (Grand, 1998, pp 67–71). We can express this pattern as follows:
At times we need an object whose data must be guaranteed never to change once it has been created. Other objects must be able to trust it completely. For example, in a banking system, it may be a business rule that once a client’s account number is assigned it may not be modified. Another example is of centralised data that is accessed from many different parts of a program. Where data must change, it is necessary to create a new instance of the immutable class. Ensuring that data is immutable wherever appropriate helps make a program more robust. A concern is to create such an object so that we can enforce this immutability – there must be no back-door to allow this value to be changed.
Therefore,
we create an immutable class where the constructor is the only place where the values of the object are set. The object must have no Set access methods and no write access properties for the immutable data. The data fields should be declared as private so that subclasses cannot access them and no other classes should be declared in the same unit. None of the object’s methods may modify the data in any way. If the Immutable object uses a subsidiary object to store the data, it may only return the values of the data or a copy of the subsidiary object, never a reference or a pointer to it.
The class in example 4.5 is a simple case of an immutable object. As an immutable class becomes more complex it is important to ensure that there are no indirect ways other objects can modify the data.
This issue of creating trustworthy data will come up again when we look at some of the differences between association and composition.
Using Properties
The flexibility of Properties
Using direct access mapping as in example 4.3 step 3 certainly cuts down the number of program lines we have to write. But have we not now effectively got global variables, the very situation that object orientation is meant to avoid?What we achieve at very little cost with directly mapped properties is the easy use that one gets with global variables while retaining encapsulation. With direct mapping the properties give open access to the underlying data variables. But at any time we can simply change the implementation of the properties to use access methods that provide the necessary protection. Other parts of the program that are well-behaved will not be aware that any change has occurred. Other parts of the program that contravene the requirements set in the access methods will, however, be blocked.
We use mapping methods for those properties where additional operations are needed beside accessing the underlying data. These operations might involve validation or may require modification or construction of a value. Where we do not need to verify or manipulate the data we can use direct access mapping confident in the knowledge that in future we can add access methods if needed. We can also combine a mapping method and direct access. It is common, for example, to use direct access to read a property but to use a Set… mapping method to write a property.
This makes it simple to read a value while providing opportunity for data validation and so on in the write (Set…) mapping method.
