Software Design 2e - DIM

226Design patternsout how to produce a particular plan of action is still a creative activity. (Actually,the analogy with gardening is not a bad one, since gardens do evolve and exhibitbehaviour, even if over longer periods than we commonly employ when thinkingabout software. Trees grow and shade new sections of the garden, some plants taketime to become established, but then take over adjacent sections, etc. Like the softwaredesigner, the gardener’s planning requires them to envisage some future state, whilehaving inadequate control of both the conditions and the quality of the materials thatwill determine the exact form that it takes.)How then do we use catalogues of design patterns? Well, the GoF advice is verymuch along the lines that patterns need to be learned, and that by studying patterns,the designer will acquire both insight into why the pattern works, and also a familiaritywith it that will enable he or she to recognize those situations where it can be usedto effect. They also advise the designer to follow the two principles of:nnprogramming to an interface, not an implementation so that a client object neednot be aware of the actual object that is used to service a particular request, as longas its form and behaviour adhere to the interface specification;favouring object composition over class inheritance, which is not to deny the usefulnessof inheritance as a reuse mechanism, but rather to observe that it should notbe over-used.From this, we can recognize that the minimum conditions for the successful use of patternswill require that the designer should:nnnacquire a ‘vocabulary’ of design patterns;be able to recognize where a pattern would provide a suitable solution;have an understanding of how to employ the pattern within the particular solution.While indexing and cataloguing of patterns forms a useful and important step towardsthe first of these goals, finding ways to support the other two is rather more problematical,although provision of case studies of pattern use may be helpful.The authors in Buschmann et al. (1996) advocate a rather different strategy,although the basic conditions for pattern use are the same as those specified above.They argue in favour of classifying a given problem in the same way that the patternsthemselves are classified, as a step towards identifying the set of potentially useful patterns.(One thing in favour of their suggested scheme of classification is that it appearsmore suited to supporting such a process than that adopted by the GoF.) Their basicprocess can then be summarized as follows.1. Specify the problem (and, if possible, any subproblems involved).2. Select the category of pattern that is appropriate to the design activity involved(architectural or design patterns).3. Select the problem category appropriate to the problem.4. Compare the problem description with the available set of patterns taken from theselected category.