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 PATTERNSGraphical 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? |