Simplicity Above Patterns
| Simplicity Above Patterns | |
| Contributors | Christian Köppe |
|---|---|
| Last modification | May 16, 2017 |
| Source | Köppe (2011)[1][2]; Köppe (2013)[3] |
| Pattern formats | OPR Alexandrian |
| Usability | |
| Learning domain | |
| Stakeholders | |
Also Known As: Keep It Simple
You want to make sure that the students do not add unnecessary complexity through blindly applying design patterns.
While learning design patterns students want to show that they understand design patterns by implementing as many patterns as possible. Most often this adds unnecessary complexity without adding value.
Therefore: Motivate the students to always give a rationale for all design patterns they have used. Make sure that they only apply a design pattern when they have not only examined the design problem at hand, but also the consequences of applying the pattern. The application of the pattern should add value to the overall design.
This pattern is considered as true invariant for the teaching of patterns of all domains, as the tendency of applying patterns excessively after being introduced to them can be found in nearly all domains.
Context
Problem
Forces
Solution
Consequences
Benefits
Liabilities
Evidence
Literature
Discussion
Data
Applied evaluation
Related patterns
Example
References
- ↑ Pattern first published in Köppe, C. (2011). A pattern language for teaching design patterns (part 1). In Proceedings of the 16th European Conference on Pattern Languages of Programs (EuroPLoP 2011) (p. 2). New York:ACM.
- ↑ Patlet published in Köppe, C. (2011). A pattern language for teaching design patterns (part 2). In Proceedings of the 18th Conference on Pattern Languages of Programs (PLoP 2011). New York:ACM.
- ↑ Pattern also published in Köppe, C. (2013). A Pattern Language for Teaching Design Patterns. In Transactions on Pattern Languages of Programming III (pp. 24-54). Springer Berlin Heidelberg.