Pattern Implementation Matters/alx

Pattern Implementation Matters
Contributors	Christian Köppe
Last modification	May 16, 2017
Source	Köppe (2011); Köppe (2013)
Pattern formats	OPR Alexandrian
Usability
Learning domain
Stakeholders

Also Known As: Implementation Matters (Implementation Matters)

Knowing is not enough; we must apply. Willing is not enough; we must do. -Johann Wolfgang von Goethe

The concept of patterns is often abstract to students when first introduced to it. Especially the solution of a pattern is described on a high abstraction level, which makes it hard for students to see how this solution could or should be implemented in a concrete context.

***

The students have difficulties with implementing the solutions of patterns if they only read or hear about them. It is hard for them to add the information necessary for the pattern implementation, which has been abstracted away during the definition of the pattern.

Similar to programming techniques, it is not sufficient to just know about the solution a specific design pattern describes in order to use it in the intended way. E.g. the concept of recursion should be implemented and played with in order to get a real understanding of it. The process of unfolding to specific needs is generally an essential part of using abstractions like patterns.

Abstract vs. Concrete. Design pattern solutions are usually given in an abstract way. The participants are described and the structure is shown in a class diagram. However, all these stay on an abstract level for the student. Even if a sample implementation is given for a specific problem, the students still might have problems on how to apply the pattern for their own concrete problem. It is not an easy task applying an abstract solution to a concrete problem.

Implementation Complexity. Some patterns are easy to implement, while others are much more complex. This difference is not easily comprehensible for students.

Code Generation. Some development tools offer support for the application of design patterns. These tools generate most of the code which makes up the important parts of a pattern implementation. The students do often not study this generated code and take for granted that this code reflects the best possible implementation of the pattern solution independent of the rest of their implementation. So if they have to implement a pattern on their own — without using the generating facilities of such an IDE — or if they have to recognize patterns in source code, they are likely to fail.

***

Therefore: let the students implement some pattern solutions themselves.

With software design patterns it is always possible to implement them, and this helps students to understand the transformation from abstract pattern solution to concrete implementation better. However, this is not always easily possible in other domains. E.g. the patterns of Alexander can mostly not be implemented in the context of a course on architecture, and educational patterns at curriculum level might also be too big to be implemented during a course on didactics. This pattern is therefore considered as an invariant in the domain of teaching software design patterns.

As Ralph Johnson says in Goldfedder & Rising: “...people can’t learn patterns without trying them out.”. It is hard for non-experienced programmers to realize the power of patterns without a concrete application of them.

The solution is supported by the pedagogical pattern Prefer Writing (Prefer Writing), which encourages the use of written exercises and includes also the writing of source code.

Having students implementing design patterns on their own helps in getting a better understanding of the solution in general. If a concrete pattern implementation is given to the students, there will be a higher chance that they recognize the participants of the pattern and the roles they play. So even if they use code generation, having implemented a pattern on their own helps them in using it the correct way and to understand the generated code.

This pattern is just a part of the whole language and should not be used in isolation. Pattern Implementation Matters (Pattern Implementation Matters) can be used in combination with Experience of Benefits (Experience of Benefits), but does not have to. After using Pattern Implementation Matters (Pattern Implementation Matters) it is advisable to also ensure a Principle-Supporting Pattern Usage (Principle-Supporting Pattern Usage) and that the students put Simplicity Above Patterns (Simplicity Above Patterns).

The applicability of this pattern depends on the domain of the patterns. If the implementation is not realistic in the scope of the educational setting due to time or space constraints, then alternatives as e.g. working with a prototype or modelling the solution could be considered.

Probably all courses on design patterns include the implementation of at least a few of them. In our course the students had, among others, to implement e.g. the Strategy (Strategy) pattern. This exercise was then also used to give them the Experience of Benefits (Experience of Benefits). Another exercise included the implementation of the Facade (Facade) pattern. Many more examples can be found in the references section.

In Head First Design Patterns many implementation exercises are included.

The assignments for the course on software architecture at the University of Vienna all require the implementation of different architectural patterns.