Difference between revisions of "Experienced Problem"
Sfrancisco (talk | contribs) (Added contributors) |
Sfrancisco (talk | contribs) (Added category) |
||
| Line 33: | Line 33: | ||
This pattern is specific for teaching design patterns to students without prior (excessive) design experience. It also can be inappropriate to let pattern users experience the problems addressed by the patterns, e.g. when teaching pedagogical patterns one should not enforce the problems addressed by pedagogical patterns. We therefore do not consider this as sufficiently high-level to be marked with one asterisk. | This pattern is specific for teaching design patterns to students without prior (excessive) design experience. It also can be inappropriate to let pattern users experience the problems addressed by the patterns, e.g. when teaching pedagogical patterns one should not enforce the problems addressed by pedagogical patterns. We therefore do not consider this as sufficiently high-level to be marked with one asterisk. | ||
==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 13:11, 4 May 2017
| Experienced Problem | |
| Contributors | Christian Köppe |
|---|---|
| Last modification | May 4, 2017 |
| Source | Köppe (2011)[1][2]; Köppe (2013)[3] |
| Pattern formats | OPR Alexandrian |
| Usability | |
| Learning domain | |
| Stakeholders | |
Also Known As: Feel the Pain, Experience of Problems
The students got exercises which require the application of design patterns. Their experience is mainly based on some school projects, and therefore limited. You want to ensure that the students look at the Context, Problem and Consequences First, but they do not focus enough on context and problem or they do not see the problem as a real problem.
Students often apply patterns without understanding why the problem really is a problem. They are not aware of the consequences if this problem is not addressed properly.
Therefore: Let the students experience the problems addressed by a pattern first hand before they implement the pattern. Make sure that they understand what consequences it has to not address these problems.
This pattern is specific for teaching design patterns to students without prior (excessive) design experience. It also can be inappropriate to let pattern users experience the problems addressed by the patterns, e.g. when teaching pedagogical patterns one should not enforce the problems addressed by pedagogical patterns. We therefore do not consider this as sufficiently high-level to be marked with one asterisk.
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.