Patterns and Anti-Patterns
How patterns and anti-patterns can help you engineer code day-to-day
A design pattern is a general repeatable solution to a commonly occurring problem in software design (Portland Pattern Repository, Wikipedia Definition). A design anti-pattern is a general repeatable "solution" to a commonly occurring problem in software design that initially appeared to be beneficial, but ultimately resulted in bad consequences that outweighed the hoped-for advantages (Anti-Patterns Home Website). Design patterns are something to take advantage of in program design, anti-patterns are to be avoided.
Design Patterns
Imagine there are three classes that all implement the same interface which defines a single method, and that each class provides a different implementation technique for this method. To create an object from one of the three classes, the code to decide which class of object to create has to be written. If the code requires that these objects are created in various locations throughout some code, the decision-making code may have to be repeated in several places. Rather than do this, one possible solution is to make use of a design pattern called the factory (Factory Method Overview). A factory abstracts over the details of the class being created, abstracting the decision making code into one place.
The string "Fast Algorithm" is used by CreateObject to decide to create an instance with the fast implementation of the method.
Significance of Design Patterns
Design patterns are useful because they raise the abstraction level so that programmers can discuss design at the conceptual level, without being distracted by implementation detail (*). Programmers have both a shared language with which to understand each other's designs and a collection of well-understood, documented patterns that they can refer to that can help them relate to another system. "Pattern spotting" in this way lets engineers quickly grasp the important details of a program's design. It allows engineers to reuse ideas, rather than implementation, thus offering engineers the opportunity to discuss the applicability of a given design approach without the need for a lot of potentially costly implementation. It can be useful to re-visit a program together with someone who is well versed in object-oriented patterns so that both of you can see where a program may be improved by the use of a pattern. You provide the program domain knowledge and they provide the pattern expertise.
Design Anti-Patterns
A design anti-pattern in an object-oriented program is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Examples of object-oriented anti-patterns:
- Creating massive classes with a huge number of methods.
- Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.
- Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work (example).
Significance of Design Anti-Patterns
Anti-patterns are useful for the same reason that patterns are useful, anti-patterns provide a way to document and spot bad design and to (hopefully) provide remedies. It's a good idea to know about anti-patterns so that your code doesn't use any, so that they can be recognised the next time code is maintained and so that their impact can be appreciated at the next code review. They should be identified as early as possible in the software life-cycle as it's easier to re-design code than unpick its implementation.
Criticisms of Patterns and Anti-Patterns
Some have criticised design patterns [4], pointing out that they don't provide reuse nor do they differ significantly from other abstractions. The purpose of design patterns is to capture commonality at the design level. Patterns can be reused once implemented; however, as soon as the design is implemented, it has become specific to the particular language and environment in which it will be deployed. The implementation of a persistence layer pattern would be radically different on a handheld device compared to one for a server environment. The pattern for these two environments will have some elements in common and this commonality can be reused at the design level. The pattern can then be decomposed and refined, one for each environment, and the individual patterns can be reused and implemented. The two patterns and the common part can then be made publically available from the Portland Pattern Repository. Patterns and their implementations compliment each other, however, one isn't a replacement for the other and patterns are design-level entities.
It's possible that patterns don't differ significantly from other abstractions and that some concepts pre-date the introduction of patterns. Patterns and anti-patterns are names given to concepts that pre-exist the use of the names. However, what is of value is the pattern community that has formed and the free exchange of information on patterns and anti-patterns.
Conclusions
Better object-oriented code can be engineered by having an appreciation of patterns (as examples of what you may want to do) and anti-patterns, as examples of what you shouldn't.
(*) Implementation details are important, but not always when communicating about abstract design.
What do you think about this article?
More in Technology
Latest Articles