From the start of the computer age, developers, engineers, scientists, hobbyists in the garage, and others have written a large body of code. Most every programming problem has been addressed in some manner in this code. You might consider your problem unique, but it is not. At a macro level, your problem may appear to be unique. However, when decomposed, the application is a composition of familiar algorithms, formulas, input, and output. Design patterns are the representation of this knowledge. For example, a singleton is a common but complex construct required in a myriad of applications. A hundred developers would implement a singleton a hundred different ways—some incorrect. Why not create the perfect singleton from the collective knowledge of all developers? The perfect singleton could then be reused. This is a quicker and more robust approach. That is the purpose of the singleton pattern.
A design pattern is a formal description of a general solution to a common software problem. This includes defining the relationship between classes and objects necessary to implement the solution. Although general, design patterns are adaptable to specific purposes. A design pattern is also both language and platform independent. Design patterns are essentially agnostic and reusable solutions.
Instead of creating an application from nothing, first analyze the application design for potential patterns: composite pattern, decorator pattern, façade pattern, singleton pattern, and others. These patterns become the building blocks for constructing your application. Wrap and bind these building blocks with a thin layer of logic and user interface, if necessary. The thin layer represents the truly unique aspects of the application. See 8-4.
Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley Professional, 1994), is an excellent book on design patterns. There are also design patterns books specific to managed languages, such as C#. At Microsoft’s Web site, www.microsoft.com/patterns, you can find a variety of information on design patterns and implementation for managed code.
There are several benefits to design patterns. Each of these benefits contributes to defensive programming:
A design pattern is a tested best practice.
A design pattern is a documented solution for a common software problem, which also makes your application more maintainable in the future.
Because it is a documented solution, a design pattern provides a basis of understanding for everyone working on a common project.
You can focus on the larger problems that are unique to your application. Ultimately, this will lead to a better application for you and your client.
Reusing solutions as described in a design pattern should make product development quicker.
Some of the common design patterns are shown in 8-2:
Table 8-2. Common Patterns and Their Descriptions
Pattern | Description |
|---|---|
Builder | The builder pattern abstracts the creation of an object, where different implementations of the objects can be constructed. |
Composite | The composite pattern allows a group of objects to be treated as a single entity or individual objects. |
Decorator | The decorator pattern makes a class extensible allowing additional class members to be added dynamically. |
Facade | The façade pattern publishes a refined interface for a large body of code. The façade pattern is frequently used with libraries. |
Factory method | The factory method pattern abstracts the creation of an object using one or more methods of a base class that can be overridden in derived classes for a refined implementation. |
Singleton | The singleton pattern creates a single instance of an object. One instance of the target object always exists—no more and no less. |