May 05, 2006
Hares, Tortoises, and the Decorator PatternPutting the Decorator Pattern to WorkRichard Vaughan
An empirical comparative study of the overheads carried by static and dynamic implementations of the Decorator pattern
Richard Vaughan provides development, training, and consultancy services in London. He can be contacted at http://www.dodeca.co.uk.
Much has been written about the Decorator pattern and its benefits in software development. From the client's viewpoint, the essence of decoration--invariance of type across object relationships--permits augmentation of functionality without change in interface. However, while many treatments of the Decorator present it solely as a dynamically constructed entity, this in fact need not be the case. In languages such as C++, the use of recursive template-instantiation allows the static construction of a decorative chain, with essentially the same properties as its dynamic counterpart; and while this approach loses the ability to configure implementation on-the-fly, it preserves the other characteristics of the pattern. This minimizes runtime overheads, and maximizes the potential for compile-time optimisations, and in certain contexts these advantages may be critical; but how much smaller, precisely, are the runtime costs of the static approach? This article is an empirical comparison of the overheads that accompany dynamic and static decoration.
The Benefits of Decoration
Whatever the implementation, the principle of decoration turns upon the reification of complex functionality into separate classes of the same type. Linking instances of these classes together allows a given method to be called on the lead object, which performs its processing, before calling the same method on the next object, and so on. The invariance in interface throughout the chain means that objects need not be concerned about the precise nature of their siblings. This allows arbitrary sequences of objects to be constructed, of arbitrary length, but with minimal inter-object dependencies and the problems these entail. The object-diagram in Figure 1 illustrates the principle.
Figure 1: Object diagram.
In essence, this approach is an alternative to augmentation of functionality through sub-classing, but without the conflation of responsibility, and the implicit dependencies, that this use of derivation would bring. This delivers clear design-time benefits: Each object can do one thing, and one thing alone, which promotes good, clean, abstractions. This, in turn, allows independent and incremental development of different areas of functionality.
On the downside, a criticism is that the high degree of granularity (lots of little classes) can result in designs that are hard to understand. However, software development is dominated by the conservation of complexity [1]. That is to say: Whichever way you do it, there is always a minimum challenge, therefore any approach that reduces the net complexity to that minimum possible is to be favoured. However, high granularity may also bring performance overheads that are disproportionate to the net functionality of the structure, and to the demands on it, thus bringing the means of implementation into question. 
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
