Design Patterns
Design patterns provide generic, reusable designs that solve problems at the design level. A design pattern does not define code and is not specific to a given programming domain. Instead, it provides a proven, tested solution for a class of similar design problems. Design patterns also lend common terminology that you can use to make your own designs easier to document and understand [Gamma 1995].
Patterns describe techniques that experts have abstracted from multiple specific solutions. Identifying and understanding patterns provide two essential benefits. First, they introduce effective design strategies to less experienced designers, alleviating them from rediscovering these patterns using trial and error. Second, they attach common names to ideas that you can readily use in conversation, design meetings, and documentation.
Design patterns are not created from theoretical examples. Experienced object-oriented designers recognize that certain object structures and interactions lend themselves more readily to maintenance and reusability than others. Just like architects and civil engineers define broad building concepts that apply at many levels, software designers assemble a set of patterns that they can apply to a variety of domains.
Many seasoned designers have taken the initiative to identify and document patterns. Design pattern catalogs consolidate related patterns in a single reference collection. The most influential design pattern catalog is the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides [Gamma 1995]. It identifies and describes patterns that solve broad object-oriented design problems. Many other more specialized catalogs exist, targeting domains such as enterprise application architecture [Fowler 2002], J2EE applications [Alur 2001, Marinescu 2002], business software [Carey 2000], embedded systems [Pont 2001], and testing [Binder 1999].
|