Discover Your Own Pattern/alx
| Discover Your Own Pattern | |
| Contributors | |
|---|---|
| Last modification | October 4, 2016 |
| Source | Köppe (2013)[1] |
| Pattern formats | OPR Alexandrian |
| Usability | |
| Learning domain | |
| Stakeholders | |
Also Known As: Pattern Discovery
The students have enough knowledge of the subject addressed by some of the more simple patterns and they probably already applied the pattern solution without knowing that this was a pattern implementation. You now want to show the students where patterns come from.
Students see patterns as something that intelligent people have written. They don’t understand that these mostly are captured “best known practices” and that experienced people use them without thinking about them.
Usually not much focus is put on where patterns come from. They are taught to students (and explained in textbooks) as if they are a mechanism invented by some experts. This does not increase the understanding of what patterns in general are and can do.
Not Invented Here. Some students prefer to design software (in assignments or projects) their own way. They think that patterns are just techniques which are invented by other people, but that they can do better. The students do not know that they already are applying implicitly some patterns.
Complexity Fear. Patterns are at different complexity levels. The Visitor (Visitor) pattern from the GoF-book is certainly more complex and harder to understand than the Singleton (Singleton) pattern[2]. Especially when beginning with patterns, this complexity can be overwhelming. The students are afraid of doing it wrong, so they often decide to not use patterns. This experienced complexity is related to their perception that they have to understand the abstract mechanism of pattern application and that this mechanism is separate from their own programming and design experiences. They do not see both as parts of the same process.
Therefore: Show students how patterns emerge by letting them discover an existing and well-known pattern by themselves.
We consider this pattern as true invariant, taking into account that it is only applicable for patterns which match with the experience of the students or pattern learners. It was for example used for introducing pedagogical patterns during a lecturer’s workshop and also during a presentation at the Dutch Conference on Computer Science Education in 2011[3].
The experience of discovering something by yourself can lead to a higher learning effect than if it is just explained. While discovering something, one uses already existing knowledge. The parts of the new knowledge can be connected to the existing knowledge, which is the implementation of the pedagogical pattern Expand the Known World (Expand the Known World) and makes use of Constructivist educational theories where knowledge is built upon existing knowledge[4].
So, if students would discover a pattern by themselves, they can more easy connect and add it to their existing knowledge. They also recognize that discovering patterns is based on the experience of the ones looking for the patterns. James Coplien states that “it is difficult for designers to appreciate patterns fully, unless they have written one”[5]. Warren also describes the experience that one sometimes subconsciously applies patterns while designing[6]. This can be used for letting students make the same experience.
Pattern discovery — or pattern mining — is usually based on many examples. The implementation of this pattern therefore requires the existence of a group of implementations or designs, all solving the same problem. Then the pattern discovery steps as suggested by Alexander[7] can be used:
One realisation could be to give students prior to the teaching of a specific design pattern an assignment which includes the problem addressed by this pattern in a well defined context. Let them implement it — without using the pattern! — and present their solution to the class.
Discuss all solutions in the class. Let the students vote on which solution or which parts of solutions are the best.
Make sure they give arguments for why they’ve chosen one of the solutions as the best one and how this could be applied to equivalent problems. Then introduce the pattern and compare it with the students’ solution. If the example is well chosen and the discussion stays focused on the important parts, the students’ solution should be nearly identical to the pattern and, if at all, only differ in minor parts. This way, the students discovered the pattern themselves.
Before providing some known uses of this pattern it is interesting to mention that by far the most examples make use of the Strategy (Strategy) design pattern for the application of this pattern.
This pattern was used in the beginning of a course on ’Patterns and Frameworks’. The students got an exercise where they had to give the design of a solution (with a UML-classdiagram) which solved the problem of maintaining a few cooks with different preparations. It should be easy to give a cook another series of preparations steps. After a short period all groups had to present their solutions and the group was discussing them. Some created a class for every cook (like cookChristian, cookJeroen, etc.), others made one class cook with an attribute name. Some decided to add a list to every cook with all preparation steps, while other solutions included an abstract class preparation with concrete implementations of different preparation strategies. The group decided after a discussion that this last solution was the best one. After that we introduced the Strategy (Strategy) pattern[2], which only differed in some minor details from the solution which was chosen as the best solution. In some later exercises and assignments the author experienced that the students’ usage of the Strategy (Strategy) pattern was nearly always reasonable.
Weiss used this pattern as basis for an undergraduate CS course[9]. Using a series of ongoing assignments, all improvements of a small application, he introduced different problems which had to be solved and implemented by the students. The solutions to these problems were subject to group discussions, and the best solutions were then applied by the students. These solutions were actually implementations of specific design patterns, which was communicated to the students after they implemented them. This showed the students that design patterns are indeed good solutions to well identified problems.
Eduardo Guerra lets his students write a pattern themselves based on their prior experience, which is also an implementation of Discover Your Own Pattern (Discover Your Own Pattern). He also works in his lecture on ”Understanding Design Patterns” together with the students towards the best possible solution for implementing a complex UI menu. The agreed-on best solution then actually is the implementation of the Strategy (Strategy) pattern, which gives the students the impression that they discovered this pattern themselves.
Kevlin Henney, independent consultant and co-author of POSA5[10], often tells people in a design and code lab in a commercial training context to focus on problem identification and problem solving. The participants of this training already have certain design knowledge, but only knowledge of a small set of design patterns. During the retrospective after finishing the lab exercise sometimes patterns become visible which the participants applied without knowing it. Linking the pattern to the presented solution is then easy to grasp for the participants, and also shows them where patterns come from. Even though this is not a conscious application of Discover Your Own Pattern (Discover Your Own Pattern), it shows the applicability of the idea behind this pattern.
Also the book Head First Design Patterns begins with the application of existing object-oriented knowledge following some basic principles, which finally leads to the implementation of the Strategy (Strategy) pattern[11].
References
- ↑ 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.
- ↑ 2.0 2.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.
- ↑ Köppe, C. (2011). Een tijd-(en grenze) loze manier van onderwijs: Pedagogical Patterns. In Proceedings of the NIOC 2011 conference. Heerlen, Netherlands.
- ↑ Bergin, J., Eckstein, J., Völter, M., Sipos, M., Wallingford, E., Marquardt, K., Chandler, J., Sharp, H., and Manns, M.L. (2012). Pedagogical patterns: advice for educators. Joseph Bergin Software Tools.
- ↑ Beck, K., Crocker, R., Meszaros, G., Vlissides, J., Coplien, J. O., Dominick, L., & Paulisch, F. (1996). Industrial experience with design patterns. In Proceedings of the 18th international conference on Software engineering (pp. 103-114). IEEE Computer Society. Washington DC.
- ↑ 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..
- ↑ Alexander, C. (1979). The timeless way of building (Vol. 1) ( p.254-260). New York: Oxford University Press.
- ↑ Astrachan, O., Mitchener, G., Berry, G., & Cox, L. (1998). Design patterns: an essential component of CS curricula. In ACM SIGCSE Bulletin (Vol. 30, No. 1, pp. 153-160). ACM.
- ↑ Weiss, S. (2005). Teaching design patterns by stealth. In ACM SIGCSE Bulletin (Vol. 37, No. 1, pp. 492-494). ACM.
- ↑ Buschmann, F., Henney, K., & Schmidt, D. C. (2007). Pattern-oriented software architecture, on patterns and pattern languages (Vol. 5). John Wiley & Sons.
- ↑ Freeman, E., Robson, E., Bates, B., & Sierra, K. (2004). Head first design patterns. O'Reilly Media, Inc..