Holistic Pattern Understanding/alx
| Holistic Pattern Understanding | |
| Contributors | Christian Köppe |
|---|---|
| Last modification | June 5, 2017 |
| Source | Köppe (2011)[1][2]; Köppe (2013)[3] |
| Pattern formats | OPR Alexandrian |
| Usability | |
| Learning domain | |
| Stakeholders | |
Also Known As: Understand Design Patterns (Understand Design Patterns), Pattern Understanding (Pattern Understanding)
During the first semesters of their study, students have obtained good knowledge of the basic concepts and techniques of their study. For a computer science student this is knowledge of programming and (object-oriented) principles as well as a good understanding of non-functional requirements like modifiability, reusability, or more general maintainability. You now want to introduce (design) patterns and make sure that the students understand and apply them as intended.
Patterns are conceptually different from other design techniques or methods, and not taking this into account when teaching them often results in students applying patterns in an inappropriate way.
When beginning with patterns, students tend to apply them blindly without thinking of the overall consequences. It seems to students that some intelligent people invented the design patterns and that using them automatically leads to a good design.
Abstraction. The concept of a pattern is often not well understood by the students, as patterns are at a higher abstraction level than e.g. programming language constructs or the graphical UML notations. This higher abstraction level makes it harder to understand what a pattern is and how to apply it. But if the overall concept of a pattern — and specifically that of a design pattern — is not understood, then there is a high probability that patterns are not applied properly.
Incompleteness. Students have to learn a lot of diverging concepts and techniques. These are often loosely coupled and not highly coherent and it is sometimes sufficient to have a good understanding of an appropriate subset of them in order to pass examinations or assessments. This is different with design patterns, as applying them incompletely — in the sense of not taking care of all aspects — increases the chance of incorrect application.
Goals. Design patterns are often used to realize non-functional requirements of a software system. Understanding the impact design patterns can have on the overall design of such a system is necessary in order to see if the goals are reached and the requirements are indeed implemented. This requires a thorough understanding of the consequences of pattern application.
Therefore: assure that students understand all aspects of patterns, their lifecycle, and how their use relates to the overall context by addressing these aspects, the lifecycle and the relations explicitly when teaching patterns.
This pattern is marked as true invariant, because independent of the domain it is important to understand the whole idea of patterns. Also with patterns of domains other than software design people tend to focus mainly on the solution part. This pattern can be implemented by choosing the appropriate patterns of this language, dependent of the domain and the context the patterns are taught in.
First of all, the students need to know all parts of a pattern. Quite often the knowledge of patterns focuses mainly on the solution. Context, Problem and Consequences First (Context, Problem and Consequences First) helps in avoiding this problem. As the students do not have a lot of experience with the problems addressed by the patterns and therefore do not see the benefits the patterns offer, expose them to the Experience of Problems (Experience of Problems) — by showing them what happens when not addressing the problem properly — themselves. Make sure they make the Best Fitting Pattern Choice (Best Fitting Pattern Choice) for resolving their problems and give them the Experience of Benefits (Experience of Benefits) of a correctly applied pattern. A concrete Pattern Implementation Matters (Pattern Implementation Matters), as without implementing a pattern themselves the whole concept of patterns will stay abstract for students.
The description of the resulting context forms an important part of a design pattern. The problem should be solved without introducing too much complexity, so the students should always put Simplicity Above Patterns (Simplicity Above Patterns). The main goal of design patterns is to help in making a good design by applying Principle-Supporting Pattern Usage (Principle-Supporting Pattern Usage).
Understanding design patterns should include the full lifecycle of these patterns — not only their application, but also their evolution[4][5]. Patterns emerge through careful observation of good solutions and the extraction of the common parts of these solutions. Applying Discover Your Own Pattern (Discover Your Own Pattern) helps in understanding the pattern evolution.
After the students’ understanding of design patterns, their parts and their lifecycle has improved, they can apply them more effectively. This will help in improving their designs, but also their design process, as the application of design patterns requires a careful consideration of all aspects of patterns.
The implementation of this pattern requires a time-intensive preparation and has to take the teaching environment into account. In settings which make use of Groups Work (Groups Work)[6], small classes and direct teacher-student interaction different approaches can be used including discussions and presentations. In a setting with large student groups and classical lectures and work assignments, the implementation of this pattern (and the other patterns of this language) should be included in the design of the assignments.
This pattern was used as new outline for the course “Patterns and Frameworks” at the Hogeschool Utrecht - University of Applied Sciences. The course was given earlier and some shortcomings were identified[7]. The new structure of the course based on this pattern addresses these shortcomings. In the beginning the focus is put on the concepts of object orientation and UML. Then a short history of patterns was presented to the students, describing the way Alexander et al. collected their pattern language[8]. The first exercises made use of the patterns Context, Problem and Consequences First (Context, Problem and Consequences First), Experience of Problems (Experience of Problems), Best Fitting Pattern Choice (Best Fitting Pattern Choice), Experience of Benefits (Experience of Benefits), but also Discover Your Own Pattern (Discover Your Own Pattern) (see the application sections of these patterns for the concrete implementation). Different exercises also made use of Pattern Implementation Matters (Pattern Implementation Matters). Later assignments in the course were of bigger scope, so the overall design of the students’ solutions was also important. The patterns Simplicity Above Patterns (Simplicity Above Patterns) and Principle-Supporting Pattern Usage (Principle-Supporting Pattern Usage) were applied in this phase of the course.
This pattern also forms the main approach used by Eduardo Guerra from the Instituto Tecnol´ogico de Aeronautica in Brazil when introducing design patterns for the first time.
The goal of the book Head First Design Patterns[9] is to teach a good understanding of design patterns. This pattern is also applied in this book as most patterns of this language are applied there as well.
Uwe Zdun, professor for software architecture at the University of Vienna, uses this pattern for the design of the work assignments in different courses on teaching architectural patterns, as there are large groups of students in the classical lectures. The assignments cover the different aspects of the patterns.
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.
- ↑ Hundley, J. (2008). A review of using design patterns in CS1. In Proceedings of the 46th Annual Southeast Regional Conference on XX (pp. 30-33). ACM.
- ↑ 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..
- ↑ 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.
- ↑ Köppe, C. (2010). Observations on the observer pattern. In Proceedings of the 17th Conference on Pattern Languages of Programs (PLoP 2010) (p. 6). New York:ACM.
- ↑ Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., & Angel, S. (1977). A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure).
- ↑ Freeman, E., Robson, E., Bates, B., & Sierra, K. (2004). Head first design patterns. O'Reilly Media, Inc..