Difference between revisions of "Best Fitting Pattern Choice/alx"
Sfrancisco (talk | contribs) (Edited source) |
Sfrancisco (talk | contribs) m (Edited format) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 4: | Line 4: | ||
{{Infobox_designpattern | {{Infobox_designpattern | ||
|image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) --> | |image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) --> | ||
|contributor= | |contributor= [[Christian Köppe]] | ||
|source= Köppe (2011)<ref>Pattern first published in Köppe, C. (2011). [http://koeppe.nl/publications/PatternsForPatternTeaching_ACM_Plop11.pdf A pattern language for teaching design patterns (part 2)]. In ''Proceedings of the 18th Conference on Pattern Languages of Programs''. | |source= Köppe (2011)<ref>Patlet first published in Köppe, C. (2011). [http://dl.acm.org/citation.cfm?id=2396718 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.</ref><ref>Pattern first published in Köppe, C. (2011). [http://koeppe.nl/publications/PatternsForPatternTeaching_ACM_Plop11.pdf 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.</ref>; Köppe (2013)<ref name="Koppe2013">Köppe, C. (2013). [http://link.springer.com/chapter/10.1007/978-3-642-38676-3_2 A Pattern Language for Teaching Design Patterns.] In ''Transactions on Pattern Languages of Programming III'' (pp. 24-54). Springer Berlin Heidelberg.</ref> | ||
|dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma --> | |dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma --> | ||
|domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) --> | |domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) --> | ||
Line 80: | Line 80: | ||
<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:Full_Pattern]] [[Category:Pattern Language for Teaching Design Patterns]] [[Category:Traditional Classroom]]<!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] --> |
Latest revision as of 10:15, 17 May 2017
Best Fitting Pattern Choice | |
Contributors | Christian Köppe |
---|---|
Last modification | May 17, 2017 |
Source | Köppe (2011)[1][2]; Köppe (2013)[3] |
Pattern formats | OPR Alexandrian |
Usability | |
Learning domain | |
Stakeholders |
Also Known As: Perfect Fit (Perfect Fit)
Teaching patterns usually involves a larger set of somehow related patterns. Books are often used in such courses which contain patterns covering different aspects of a certain domain. After being exposed to the patterns, the sheer amount of them — and in some cases their similarities — make it difficult for students to immediately choose and apply these patterns in the intended way.
Students often choose inappropriate patterns without exploring if the problem they have is the same as the problem addressed by the pattern. And even if this fits, the context or forces may be different or the consequences are worse than the original problem. If pattern names are part of the vocabulary of a domain, choosing an inappropriate pattern also leads to miscommunication.
One of the underlying problems is that students have difficulties with determining which pattern to use for a specific problem[4], even if the problem is described properly.
Solution-focused. Some design patterns describe similar solution structures for solving different problems, like the Adapter (Adapter), Proxy (Proxy), and Facade (Facade) patterns. The differences between these patterns are mainly in their intentions. If not all parts of the pattern are examined, then it might seem that different solutions could be applied to solve the problem at hand. Technically all these solutions could be working, but often the role-names of pattern participants — as suggested in the the GoF-book[5]— are used as parts of the class- or methodnames of the concrete pattern implementation. Using the solution of the wrong pattern would therefore communicate the wrong intention.
Vague Problem Description. Some design patterns offer different solutions to similar problems, like the Interpreter and Command pattern. If the design problem is — or can — only be vaguely identified, then it’s hard to determine which pattern to use, because it can seem that the problem/context-part of more than one pattern matches the problem. It also will be harder to understand the consequences completely.
Big Problem Space. Often there is more than one design problem which needs to be addressed. Choosing a pattern based on just one of these problems could have a negative effect on the other problems.
Example-based Learning. If examples are used which come from books or websites, then these examples often do not state a (sufficient) reasoning of why the applied pattern has been chosen to solve the example problem. This can be because there is not really a problem at hand, which is often the case with e.g. websites which focus on the implementation of patterns and not the correct application. Students tend to look for examples where patterns were applied in a context similar to their own. But if this example application is based on the wrong decisions or a misunderstood problem, then also the students will apply the possibly wrong pattern.
First Shot Solution. While looking for an applicable pattern, students tend to stop after finding the first possible solution to implement. So they are using “first possible solution” as stop condition for their search, which is faster than determining all possible patterns, studying their descriptions and making a wellgrounded choice of one these patterns. Even if this is technically working, it could communicate a wrong intention.
Therefore: Ensure that the students have analysed the design problem, context, forces, and consequences sufficiently, and that all match with the pattern they choose. It is also important that the resulting context and the fitting to other applied patterns and the overall design has been taken into account.
This pattern is a true invariant. Independent of the domain, problems can look similar in different contexts or different solutions exist for the same problem with different consequences. The correct application of patterns always requires a careful consideration of the possible alternatives and grounded choice for one of them.
A metaphor will demonstrate this pattern: A good doctor will not immediately subscribe aspirine when one has headache, but will look at all — or the most — possibly relevant symptoms in order to determine the real cause of the headache and the appropriate treatment of it. She will also take possible adverse reactions and interactions with other medicines into account.
Applying the solution of this pattern requires that the students have all needed information available and examine the Context, Problem and Consequences First (Context, Problem and Consequences First). A sensible analysis of the existing problems and the applicable patterns increases the chance of applying the correct pattern. The application of patterns often requires trade-offs[6].. The results of such a sensible analysis form the basis for making these trade-offs.
The design patterns described by the GoF[5] are grouped in three categories: behavioral, structural, and creational patterns. These categories can help with scoping the problem spaces of the specific patterns. So determining the category where a problem actually belongs to could help to decrease the number of pattern candidates which have to be examined. Knowing that there are not that many pattern candidates left can help in the decision to examine them all vs. choosing the first possible solution found.
The problem space should be kept small when applying this pattern in the beginning of a course on design patterns. It is necessary that students first grasp the idea of patterns and do apply them in small scale examples[4].
However, applying Best Fitting Pattern Choice (Best Fitting Pattern Choice) also includes a discussion of traditional, naive, and non-patterns-based approaches for solving the problem at hand[7]. This ensures that if a pattern does not offer the best solution or comes for the price of a much higher complexity in the resulting context, then it is better to put Simplicity Above Patterns (Simplicity Above Patterns) and use one of the traditional or naive approaches.
One application of this pattern was included in an exercise during the course on Patterns & Frameworks at the Hogeschool Utrecht which was done after introducing the students to the design patterns Adapter (Adapter), Proxy (Proxy), and Facade (Facade). They were then given following problem statement and asked to choose one of the previously taught patterns for solving it: “A client needs only to access the last results and the table of a football administration system”. All three patterns were chosen by some students, and we encouraged a discussion about why the different patterns were chosen. It was made clear that probably all of them could be used to implement the required functionality, but that only the Facade (Facade) pattern matches with the real problem and also communicates that. This way the students were made aware of the fact that it is not sufficient to just apply a solution of one pattern, but to make sure that pattern and problem match and therefore the implementation also communicates the intent of the pattern application.
In other discussions the students were constantly asked why they did not use another pattern. The teacher here asked on purpose for incorrect patterns in order to initiate a discussion and create an awareness of making sure that indeed there is a Best Fitting Pattern Choice (Best Fitting Pattern Choice).
The authors of Head First Design Patterns[8] mention that before applying a pattern the user should study other patterns first which look like they could be applicable too. Based on the matching of the different parts — they name intent and applicability, which include the problem, context and also consequences of a pattern — with the situation at hand a fitting pattern can be selected.
Bauer and Baumgartner cite Best Fitting Pattern Choice (Best Fitting Pattern Choice) (under the synonym Perfect Fit (Perfect Fit)) in their forthcoming book on E-Portfolio Patterns[9]. They encourage students to make use of it when applying the patterns from the book for the creation of their E-Portfolio. This is an example from the domain of education.
In the assignments given in the course on software architecture at the University of Vienna the students are required to give the rationale behind their choice of applied patterns. This included a discussion of the problem, context, and consequences of the applied pattern, but also a rationale of why other patterns were not applicable.
References
- ↑ Patlet 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.
- ↑ Pattern first 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.
- ↑ 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.
- ↑ 4.0 4.1 Pillay, N. (2010). Teaching Design Patterns. In Proceedings of the SACLA conference. Pretoria, South Africa.
- ↑ 5.0 5.1 Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design Patterns: elements of reusable object-oriented software. Addison-Wesley: Boston, MA.ISBN 0-201-63361-2.
- ↑ Warren, I. (2005). Teaching patterns and software design. In Proceedings of the 7th Australasian conference on Computing education-Volume 42 (pp. 39-49). Australian Computer Society, Inc..
- ↑ Gestwicki, P., & Sun, F. S. (2008). Teaching design patterns through computer game development. Journal on Educational Resources in Computing (JERIC), 8(1), 2.
- ↑ Freeman, E., Robson, E., Bates, B., & Sierra, K. (2004). Head first design patterns. O'Reilly Media, Inc..
- ↑ Bauer, R., & Baumgartner, P. (2012). schaufenster des lernens: eine sammlung von Mustern zur arbeit mit e-Portfolios. Waxmann.