IF you find yourself in CONTEXT
for example EXAMPLES
with PROBLEM
entailing FORCES
THEN for some REASONS
apply DESIGN FORM AND/OR RULES
to construct SOLUTION
leading to NEW CONTEXT and OTHER PATTERNS
Graphical notations can help, expecially with showing relations
among pattern objects/classes. But they are not sufficient.
We need to give several types of information about the problem domain, the forces acting in the sytem, and the resolution to which a pattern is to be applied.
This is not the only format used to describe design patterns but it is a popular one, from the GoF text.
| name and classification | classification by "creational", "structural", "behavioral" |
| intent | what does the design pattern do? rationale? what design issues or problems does it address? |
| aka | names that are common as alternatives |
| motivation | scenario to illustrate a design problem and how this pattern solves it. |
| applicability | situations in which this pattern may be applied? examples of poor design to which it may be applied? how can one recognize when to use this pattern? |
| structure | graphical representation of classes (UML) |
| participants | classes and responsibilities |
| collaborations | how do these participants interact? |
| consequences | how does the pattern support the objectives? trade offs when using the pattern? what system structures may be varied independently of the pattern? |
| implementation | pitfalls, hints, for using this pattern... language-specific issues |
| sample code | as extra illustration |
| known uses | from real systems. Need at least two frm different domains. |
| related patterns | are there similar patterns; though related, what are the essential differences? what other patterns are generally used with this one? |