Posted in: J2EE Design Patterns
What is a software design
pattern?A design pattern is a solution to a general software problem within a particular context.
Context:
A recurring set of situations where the pattern applies.
Problem:
A System of forces (goals and constraints) that occur repeatedly in this context.
Solution:
A description of communicating objects and classes (collaboration) that can be applied to resolve those forces.
Why is the study of patterns important?
As initial software designs are implemented and deployed, programmers often discover improvements which make the designs more adaptable to change. Design patterns capture solutions that have evolved over time as developers strive for greater flexibility in their software, and they document the solutions in a way which facilitates their reuse in other, possibly unrelated systems. Design patterns allow us to reuse the knowledge of experienced software designers.
3)How do I document a design pattern?
A pattern description must address the following major points:
Pattern Name and Classification
A short, meaningful name for the pattern, usually only one or two words. Names provide a vocabulary for patterns, and they have implied semantics – choose names carefully. Following the GoF book, we can also group patterns into higher level classifications such as creational, structural, and behavioral patterns.
Problem:
A general description of the problem context and the goals and constraints that occur repeatedly in that context. A concrete motivational scenario can be used to help describe the problem. The problem description should provide guidance to assist others in recognizing situations where the pattern can be applied.
Solution:
The classes and/or objects that participate in the design pattern, their structure (e.g., in terms of a UML class diagram), their responsibilities, and their collaborations. The solution provides an abstract description that can be applied in many different situations. Sample Code in an object-oriented language can be used to illustrate a concrete realization of the pattern.
Consequences:
A discussion of the results and tradeoffs of applying the pattern. Variations and language-dependent alternatives should also be addressed.
Known Uses:
Examples of the pattern in real systems. Look for applications of the pattern in language libraries and frameworks, published system descriptions, text books, etc. Not every good solution represents a pattern. A general rule of thumb is that a candidate pattern (also called a “proto-pattern”) should be discovered in a minimum of three existing systems before it can rightfully be called a pattern.
The following quote by Robert Martin highlights the importance of providing pattern descriptions: “The revolutionary concept of the GoF book is not the fact that there are patterns; it is the way in which those patterns are documented. ... Prior to the GoF book, the only good way to learn patterns was to discover them in design documentation, or (more probably) code.”
4)Where can I learn more about design patterns?
The best place to start is the seminal work by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (collectively known as the “Gang of Four” or simply “GoF”) entitled
Warning: This book is not light reading. From the Preface: “Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing.”
It is, however, a book which wears well over time, and it is definitely worth the effort required to work through it.
What is an example of a design pattern?
Following the lead of the “Gang of Four” (GoF), design pattern descriptions usually contain multiple sections including
* Intent
* Motivation
* Applicability
* Structure
* Participants
* Collaborations
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns
A complete discussion of even a small pattern is beyond the scope of a simple FAQ entry, but it is possible to get the idea by examining an abbreviated discussion of one of the simplest and most easily understood patterns. Consider the Singleton pattern, whose intent reads as follows:
Intent: Ensure that a class has one instance, and provide a global point of access to it.
Almost every programmer has encountered this problem and formulated an approach for solving it in a general way – some solutions are better than others. The solution offered by the GoF would look something like the following when coded in java.