Templates for Patterns and AntiPatterns

The use of templates is what makes design patterns and AntiPatterns different from other forms of technical discussion. The template assures that important questions are answered about each pattern in a pattern language, pattern catalog, or pattern system


Degenerate Form


Degenerate patterns are without discernible templates. Compared to templated patterns, a degenerate pattern contains only a single content section. Here is an example of a degenerate pattern form.


Degenerate Pattern Form


Technical Discussion: What does the author have to say about this set of concepts?


Is it a pattern? It’s a subjective judgment. One can call it a pattern because the author has chosen to do so. We choose not to believe it’s a pattern solely based upon the author’s reputation or other subjective assessments.


Degenerate form provides no particular conventions or guidance upon which practitioners can rely. The readers have to analyze the author’s prose to determine what is problem, intent, context, forces, solution, benefits, consequences, examples, and so forth. In practice, it is likely that one or more of these elements are missing.

Alexanderian Form


Christopher Alexander’s traditional template comprises three sections: name, problem, and solution. The word THEREFORE partitions the discussion. THEREFORE appears between the discussion of issues and the discussion of a design approach. Here is an example of an Alexanderian pattern form.


Alexanderian Pattern Form


Name: What does the author call this concept?


Technical Discussion: What are some related issues?


THEREFORE


What is a common solution for resolving these issues?


The Alexanderian form contains an essential partitioning between motivations and actions. By convention, a diagram is included in the Alexanderian form. This is an important spatial abstraction of the ideas presented in prose. The Alexanderian form is the minimum one should expect for the description of any design pattern.


Minimal Template (Micro-Pattern)


The minimal, rhetorical structure of a software-engineering design pattern includes name, problem, and solution. The name defines unique terminology; the problem lists the context, forces, and/or applicability; and the solution is the pattern content (what to do about solving the problem). This structure is appropriate for low-overhead pattern documentation such as workshop-pattern development or on-site consulting, where expedience and content are key, and formality is not necessary. It’s also concise, which is a requirement of some publication media. Here is the standard template for a micro-pattern.


Micro-Pattern Template


Name: What shall this pattern be called by practitioners?


Problem: What is motivating us to apply this pattern?


Solution: How do we solve the problem?


Mini-Pattern Template


A mini-pattern decomposes the problem or solution to expose the teaching elements. The next most important rhetorical aspects of a pattern are the “teaching” elements. In particular, the context and forces and/or the benefits of consequences. Most important, these sections answer the why questions about the solution, as well as provide information about when to use the pattern. Here are two examples of mini-pattern templates.


Inductive Mini-Pattern


Name: What shall this pattern be called by practitioners?


Context: What are the assumed environment or a priori assumptions for applying this pattern?


Forces: What are the different design motivations that must be balanced?


Solution: How do we solve the problem?


Deductive Mini-Pattern


Name: What shall this pattern be called by practitioners?


Problem: What is motivating us to apply this pattern?


Solution: How do we solve the problem?


Benefits: What are the potential positive outcomes of applying this pattern?


Consequences: What are potential shortcomings and consequences of applying this pattern?


We describe two template forms for mini-patterns: inductive and deductive. The inductive mini-pattern focuses on the applicability of the pattern. The deductive mini-pattern focuses on the outcomes of the solution—benefits and consequences.




Formal Templates


There are many other potential sections added to a pattern and AntiPattern write-up. Citations that include reference to other related patterns and nonpattern technical concepts are also useful and necessary for a full formal treatment. Some of the formal templates used in publications are summarized here. Note that the following are paraphrased summaries of the authors’ original template definitions. The Gang-of-Four (GoF) template is a formal template appropriate for micro-architecture-level patterns [Gamma 94].


Gang-of-Four Pattern


Pattern Name: What is the pattern called?


Pattern Classification: Is the pattern creational, structural, or behavioral?


Intent: What problem does this pattern solve?


Also Known As: What are other names for this pattern?


Motivation: What is an example scenario for applying this pattern?


Applicability: When does this pattern apply?


Structure: What are the class hierarchy diagrams for the objects in this pattern?


Participants: What are the objects that participate in this pattern?


Collaborations: How do these objects interoperate?


Consequences: What are the trade-offs of using this pattern?


Implementation: Which techniques or issues arise in applying this pattern?


Sample Code: What is an example of the pattern in source code?


Known Uses: What are some examples of real systems using this pattern?


Related Patterns: What other patterns from this pattern collection are related to this pattern?


System of Patterns Template


The system of patterns template is a formal template appropriate for multiple levels of patterns, such as idioms level, application level, and system level [Buschmann 96].


Name: What is this pattern called?


Also Known As: What are other names for this pattern?


Example: What is an example of the need for this pattern?


Context: When does this pattern apply?


Problem: What is the problem solved by this pattern?


Solution: What is the underlying principal underlying this pattern?


Structure: What objects are involved and related (structural diagram)?


Dynamics: How does this object collaborate (interaction diagram)?


Implementation: What are some guidelines for implementing this pattern?


Example Resolved: Show how the previous example is resolved using the pattern.


Variants: What are important variations of this pattern?


Known Uses: What are real-world systems using this pattern?


Consequences: What are the benefits and liabilities of using this pattern?


See Also: What are related patterns and how do they differ?



Rethinking the Design Pattern Template


Many practical experiences with formal templates were less than satisfactory for early pattern readers and practitioners. Patterns usually convey a fairly simple idea. However, many readers found the write-ups to be overly concerned with verbose details, issues, and preliminary discussion. This is an interesting reaction, given that pattern templates have come a long way from the enigmatic “degenerate templates.”


What was needed was a way to convey the information quickly and conveniently. One key approach that we used was to leverage the templates upon a robust reference model. Instead of having each pattern be completely independent (in terms of context and forces), the CORBA Design Patterns reference model allowed us to define the horizontal (common) context and forces that occur at each scale of software design. By addressing this commonality in a separate reference-model chapter, we eliminated several pages of verbose preliminary discussion from virtually every pattern.


In addition, we wanted to structure the template for quick comprehension. Given that there are many patterns to learn and assimilate, and most practitioners are under extreme time pressures on the job, we organized the template sections to enable readers to learn a great deal about a pattern, before being subjected to a rambling, free-text discussion.


The CORBA Design Patterns template is organized so that the most concise information-packed sections are first and the free-form sections are last. The template begins with keywords defined in the reference model, followed by a summarized intent and a diagram abstraction of the solution. Applicability is a priority-ordered, bulleted list that quickly covers the most important motivations for using the pattern. The solution summary explains the patterns’ technical approach crisply. Sections following the solution summary make this feasible.


In practice, we found that discussion of variations in the solution section really confuses some readers. A separate section is dedicated to the variations of the solution, so that the solution is explained without the confusing appearance of ambivalence or caveats. Another section that covers alternative software scale describes the patterns’ differences when applied at another level of software design.


CORBA Design Pattern Template


Solution Name:


Solution Type: Is it a software pattern, technology pattern, process pattern, or role pattern (keyword only)?


Intent: What is this pattern all about, in 25 words or less?


Primal Forces: Which of the horizontal forces from the reference model are best resolved by this pattern?


Applicability at this Scale: When does this pattern apply; what are the significant motivations behind this pattern (ordered bullet list)?


Solution Summary: What is the pattern solution and approach (stated clearly, without verbose embellishment)?


Benefits: What are the primary positive results of applying this pattern (bulleted list)?


Other Consequences: What are the primary negative consequences of applying this pattern (bulleted list)?


Rescaling this Solution to Other Levels: How does this pattern differ if applied at other software scales?


Related Solutions: Cross-references and citations to other patterns (including other patterns from other pattern publications) and other technology examples, publication citations, and resources. Basically, point to anything outside this pattern write-up that may be of use to the reader.


Example: A practical example of this pattern in an application context, with source code listing if applicable.


Background: Any other relevant information?



AntiPattern Templates


AntiPatterns are a new form of patterns. A fundamental difference between a pattern and an AntiPattern is that with an AntiPattern a solution has negative consequences. Some consequences may be apparent now (the symptoms) and some may be anticipated (the consequences). There are basic forms of AntiPatterns.


To be useful, AntiPatterns also include a solution. So another way to differentiate between a pattern and an AntiPattern is that there are two solutions (instead of a problem and a solution). The first solution generates negative consequences (forces that must be resolved). The second solution is a migration (or refactoring) from the first solution that provides dramatically improved benefits and much-reduced consequences.


In an ordinary design pattern, the convention is that at least three known uses of the solution must exist. Because there are two solutions, the “rule of three” for AntiPatterns is different from patterns. Since no three solutions are identical, the pattern solution is a best-practices abstraction of the known uses.


AntiPatterns are different because they have two solutions. The first solution, “the AntiPattern,” must conform to the rule-of-three occurrences just as with ordinary patterns. Unfortunately, it’s very unlikely that each of these known occurrences of the AntiPattern were resolved in exactly the same way. The second solution is a best-practices solution, based upon the known solutions to the AntiPattern, if multiple solutions are known to exist. They can be identified in the template as well.


Pseudo-AntiPattern Template


This is a form of degenerate template in which the author describes a bad solution in disparaging terms. Some of the earliest AntiPatterns posted on the Internet had this form. This is not a particularly useful form, because it’s subjective and quite one-sided in its pejorative tone.


Name: What is the AntiPattern called?


Problem: What are its derogatory characteristics?


Mini-AntiPattern


As we discussed, an AntiPattern template differs from a pattern in that it presents two solutions. The first solution is called the AntiPattern problem; the second solution is called the refactored solution. This minimal form can be extended with other template sections as appropriate.


Name: What shall this AntiPattern be called by practitioners (pejorative)?


AntiPattern Problem: What is the recurrent solution that causes negative consequences?


Refactored Solution: How do we avoid, minimize, or refactor the AntiPattern problem?


A mini-AntiPattern can include a cartoon or an anecdote in a sidebar format, along with a discussion of how the AntiPattern is resolved. It’s similar in purpose to micro-patterns and mini-patterns that provide a concise pattern description with a little less formality.


Full AntiPattern Template


The following AntiPattern template is used throughout the remainder of this book to fully document AntiPatterns. A number of simpler AntiPatterns are contained in sidebars in a minimal format called a mini-AntiPattern (previous template). The full AntiPattern template comprises a number of required and optional sections. The core sections are the general form of the AntiPattern and the refactored solution. They provide the solution/solution pair that comprises an AntiPattern.


• AntiPattern Name. The AntiPattern name is a unique noun phrase. It’s intended to be pejorative. The solution name of the pattern introduces new terminology. The name is used for future reference to the principles contained in the AntiPattern. It’s important that every AntiPattern have a name, in order to uniquely identify it. Names are critical as they form the basis for an organization’s terminology when members discuss and document software and architectures.


• Also Known As. This identifies additional popular or descriptive names and phrases for this AntiPattern.


• Most Frequent Scale. Scale is indicated via a keyword from the reference model. This section identifies where this AntiPattern fits into the software design-level model (refer back to Figure 2.7). Each pattern is logically placed where the AntiPattern is most applicable. A secondary consideration for placement concerns the scale of the resulting solution. You can choose from idiom, micro-architecture, framework, application, system, enterprise, or global/industry. Scale also scopes the dimensions of the solution. Some patterns define useful solutions at several scales. The form of the rescaled solutions is also described in the AntiPattern template.


• Refactored Solution Name. This identifies the refactored solution pattern.


• Refactored Solution Type. This section contains keywords from the reference. From SDLM, it identifies the type of action that results from the AntiPattern solution. You can choose from software, technology, process, or role. Software indicates that new software is created by the solution. Technology indicates that the solution entails acquisition of a technology or product. Process indicates that the solution entails pursuing a process. Role indicates that the solution entails assigning responsibility to an individual or group. These four different kinds of solution types are detailed as follows:


1. Software patterns comprise the overwhelming majority of the patterns included in the AntiPatterns catalog. Software patterns involve the creation of new software. The vast majority of the design patterns currently available in the industry are software patterns.


2. Technology patterns solve software problems through adoption of a technology such as Java, as opposed to programming the capability from scratch. Technology patterns are also design patterns in that they result in software design and implementation, although the method of acquisition is different. Technology patterns may involve some programming, for example, creating an object wrapper for a commercial software module.


3. Process patterns provide the definition of activities that are consistently repeatable for a given solution.


4. Role patterns solve software problems by allocating clear responsibilities to organizational stakeholders. Process and role patterns are included because of the significant effect that communication and the human organization have upon software problem solving. Occasionally, we have found that a simple process or clarification of responsibilities provides the most effective action lever for solving a technical problem.


• Root Causes. This section contains keywords from the reference model. These are the general causes for this AntiPattern. Derived from the section on root causes in Chapter 2, choose from: haste, apathy, narrow-mindedness, sloth, avarice, ignorance, pride, or responsibility (the universal cause).


• Unbalanced Forces. This section contains keywords from the reference model, and identifies the primal forces that are ignored, misused, or overused in this AntiPattern. The choices include management of functionality, management of performance, management of complexity, management of change, management of IT resources, and management of technology transfer. Risk is an underlying force for all of these options. Note that management of IT resources pertains to general resource tracking and allocation issues, including finances.


• Anecdotal Evidence. This is an optional section. Often-heard phrases and comedic material associated with this AntiPattern appear in this section.


• Background. This is an optional section. The background can contain further examples of where problems occur or general background information that is useful or interesting.


• General Form of this AntiPattern. This section often includes a diagram, which identifies the general characteristics of this AntiPattern. This is not an example, but a generic version. A prose description explains the diagram (if any) and gives the general description of this AntiPattern. The refactored solution resolves the general AntiPattern posed by this section.


• Symptoms and Consequences. This is a bulleted list of symptoms and consequences that result from this AntiPattern.


• Typical Causes. This is a bulleted section in which the unique causes of this AntiPattern are identified (in addition to the root cases identified previously).


• Known Exceptions. AntiPattern behaviors and processes are not always wrong, and often there are specific occasions when this is the case. This section briefly identifies the primary exceptions to each full AntiPattern.


• Refactored Solutions. This section explains a refactored solution that resolves the forces in the AntiPattern identified in the general form section. This solution is described without variations; those are addressed in the variations section. The solution is structured in terms of solution steps.


• Variations. This is an optional section that lists any known major variations of this AntiPattern. In addition, if there are alternative solutions, they are described here as well. The variations section exists partly in order to enhance clarity in the general form and refactored solution sections. The solutions are explained clearly, without caveats about major options and alternative design points. The variations section includes these extensions, which expand upon the capabilities of the solution.


• Example. The example demonstrates how the solution is applied to the problem by paralleling the details of the solution. This section typically includes the following elements: problem diagram, problem description, solution diagram, and solution description. This section includes one or more examples of the AntiPattern abstracted from experience.


• Related Solutions. This section identifies any citations or cross-references that are appropriate. Any AntiPatterns that are closely related to this one are listed and the differences are explained. Relationships with design patterns from other pattern languages are identified and explained. Detailed citations are contained in the bibliography in the back of the book. The references to related patterns are an important aspect of the AntiPatterns. Each AntiPattern resolves some forces and creates new ones. The new forces can be resolved by related patterns, either at the same or another level. This section also highlights differences between similar patterns.


This section also includes related terminology, references, and resources. Related terminology is explained for two reasons: to distinguish our definitions from other terms using similar names, and to connect related concepts referred to by different names. These two ambiguities are the source of much confusion in software engineering circles. References include well-known terminology, example technologies, and relevant research. The references are particularly useful to experts who can use this information to rapidly relate this pattern to other known work. If an expert reviewer fully understands one or more of the references, then the core ideas of the pattern are already known by a different terminology. (We have encountered this effect in the use of other pattern languages. It sometimes takes significant time to resolve these terminology differences without this useful section.) This section serves as both a reference list and as an “also-known-as” list of synonyms with respect to other work. Resources include pointers to other kinds of information and organizations that address the problem.


• Applicability to Other Viewpoints and Scales. This section defines how the AntiPattern impacts the remaining viewpoints: managerial, architectural, or developer. It also describes the relevancy of the pattern to other levels. If a pattern assumes a different “name” at different levels, then it should be mentioned here. Some key questions addressed in this section include: What happens when the AntiPattern is applied at different levels? How effectively does it resolve the forces at the other scales? What new forces are introduced, and are they resolved as well? How do the key forces influencing the design patterns change with scale? How do the roles of the key design elements change with scale?


The AntiPatterns in Chapters 5–7 utilize this template to document the common dysfunctional practices in the software industry and suggests practical solutions that have been proven effective on at least three known occasions. These chapters discuss software development AntiPatterns, architectural AntiPatterns and managerial AntiPatterns. These levels were chosen to provide a comprehensive coverage of the critical issues involved in software projects.