Software Design 2e - DIM

10.2.4 The design anti-patternThinking about software reuse (as exemplified by the concept of the design pattern)understandably tends to focus upon how we can find ways to reuse good experiences.But of course, it is sometimes important that we should also promulgate experiencesof unsuccessful attempts at design solutions too, if only to ensure that others avoid thesame pitfalls. So, not surprisingly, although much less well codified than the conceptof the design pattern, this has led to the concept of the design anti-pattern.As described in Long (2001), design anti-patterns are ‘obvious, but wrong, solutionsto recurring problems’. In a very readable, if rather tongue-in-cheek, paper JohnLong provides a number of examples of this concept, largely focusing on the processesinvolved. Indeed, the anti-patterns literature does tend to put more emphasis upon thereasons why wrong solutions are adopted, rather than on the forms of the wrong solutionsthemselves (Brown et al., 1998).This emphasis is quite understandable, since technical solutions are rarely completelywrong in themselves, although a given solution may be the wrong one to adoptin a particular context. So, while the literature on design patterns emphasizes solutionstructures, although recognizing the influence of context and motivation, the antipatternsliterature chiefly emphasizes motivation.For our purposes, the main message here is that reuse (a concept which underpinsthe whole rationale for patterns) is not automatically a ‘good thing’. While reuse ofexperience, especially where it concerns workable solutions, represents desirable practice,it does always occur within a larger context which may itself act to increaseor reduce the benefits. We will return to some of these issues when we later come toexamine component-based design practices.225Designing with patterns10.3 Designing with patternsHaving established just what a design pattern is, and examined examples of howthey are structured and organized, the next obvious question is ‘how do we use designpatterns to solve design problems?’. In this section we examine such guidance as isavailable, and consider one of the consequences of pattern use, which is how these aremost effectively indexed.10.3.1 How to use patternsBooks that describe design patterns, such as Gamma et al. (1995) and Buschmannet al. (1996) very much function as catalogues of design patterns. In the early chapterswhich looked at the wider context of software design, we observed that catalogues aremore common in other domains and uncommon for software design, where most ofthe literature addresses design processes. Unfortunately, much as a garden cataloguefull of glorious colour photographs of healthy, thriving plants provides little real aidto the task of planning a new garden, beyond telling us which plants like shade andhow tall the various varieties (may) grow, so it is with design patterns. Possession ofthe catalogue provides a source of ideas, it provides information that helps with planningand with anticipating any possible consequences, but the design task of working