And even Gamma et al. say, to describe a pattern you need: - The pattern name.
- The problem that describes when to use a pattern.
- The solution which provides an abstract description of the design problem and its solution using necessary and affected elemnts like classes etc. (### redundancy here? why again the design problem ###).
- The consequences are the results and trade-offs of applying the pattern. The consequences are most important for somebody who likes to compare patterns for solving a specific problem.
Another point is, that very often a pattern based approach is used or is relevant to identifying the problem: E.g. if you like to discuss the Value Object/Data Transfer Object Pattern, you'd like to mention problems that lead to the use of the Session Fassade or, additionally the Composite Entity.
I would therefor suggest to always think of a pattern based approach to identify the problem and to describe the solution.
|