Difference between revisions of "Simplicity Above Patterns"
Sfrancisco (talk | contribs) (Added contributors) |
Sfrancisco (talk | contribs) (Added category) |
||
| Line 34: | Line 34: | ||
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. | 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== | |||
<!-- Context of the design pattern --> | |||
==Problem== | |||
<!-- Problem the design pattern solves --> | |||
==Forces== | |||
<!-- List of forces affecting the solution. Each entry is preceded by an * For example: | |||
# Entry 1 | |||
# Entry 2 --> | |||
==Solution== | |||
<!-- Solution to the design problem --> | |||
==Consequences== | |||
===Benefits=== | |||
<!-- List of benefits from applying the solution to the problem Each entry is preceded by an * For example: | |||
# Entry 1 | |||
# Entry 2 --> | |||
===Liabilities=== | |||
<!-- List of liabilities from applying the solution to the problem Each entry is preceded by an * For example: | |||
# Entry 1 | |||
# Entry 2 --> | |||
==Evidence== | |||
===Literature=== | |||
<!-- Evidence from literature that was used in producing the pattern or evaluating the pattern--> | |||
===Discussion=== | |||
<!-- Discussion with experts or stakeholders used in producing the pattern --> | |||
===Data=== | |||
<!-- Evidence from data that was used in producing the pattern --> | |||
===Applied evaluation=== | |||
<!-- Results from randomized controlled trials (RCTs) or similar tests that measures the pattern's effectiveness in an actual application. For example, compare student learning gains in an online learning system with and without applying the pattern. --> | |||
==Related patterns== | |||
<!-- Other design patterns related to the current design pattern and a description of how it is related --> | |||
==Example== | |||
<!-- Example of applying the design pattern --> | |||
==References== | ==References== | ||
<references/> | <references/> | ||
[[Category:Design_patterns]] <!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] --> | [[Category:Design_patterns]] [[Category:Patlet]] <!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] --> | ||
Revision as of 12:49, 5 May 2017
| Simplicity Above Patterns | |
| Contributors | Christian Köppe |
|---|---|
| Last modification | May 5, 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 (p. 2). ACM:New York.
- ↑ 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. ACM:New York.
- ↑ 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.