Context, Problem and Consequences First/alx

Context, Problem and Consequences First
Contributors	Christian Köppe
Last modification	May 17, 2017
Source	Köppe (2011); Köppe (2013)
Pattern formats	OPR Alexandrian
Usability
Learning domain
Stakeholders

Also Known As: First Things First (First Things First), Focus Beyond the Solution (Focus Beyond the Solution)

Success depends upon previous preparation, and without such preparation there is sure to be failure. -Aristotle

After an initial introduction to patterns, the students will be required to apply them as well. The application requires the choice of a pattern and the application of its solution. You now want to show students how to start applying patterns in a correct way.

***

Students who start to learn patterns often go straight to the solution and apply it, hastily skipping the problem, context, forces, and consequences parts of the pattern.

Students often think that the obvious way to show that a pattern has been understood is by implementing its solution. This is reasonable considering that patterns are often presented with a strong focus on the structure of the solution.

Visual vs. Textual. The structure of the solution of a pattern is often re-presented with a diagram. Pictures and diagrams are easier to remember than text, so students focus on these while exploring patterns for themselves. Putting the focus mostly on the diagram without examination of the textual parts of the pattern description as well — which contain also the addressed problem(s), the forces of the pattern and the consequences — leads to a high chance that they are applying a solution without solving a real problem.

Focus. Many websites which provide information on design patterns give a diagram of the structure of the solution as the first non-text element in a pattern description, which attracts the attention and therefore the focus of the reader as well. So it is not surprising that students tend to look at the solution first and then tend to try to implement this solution without further examination of what their problem consists of. But even experienced software developers often see the diagram as representation of a pattern — people think the diagram is the pattern.

Example-based Learning. If the students want to implement a pattern they look for example implementations of it. These example implementations often fall short if it comes to the description of the context and problem this specific implementation addresses, but also what the consequences are after applying the pattern. This encourages the student’s perception that design patterns are just implementation techniques.

***

Therefore: Focus first on the context and the problem (including the forces) addressed by the pattern and the consequences of applying the pattern. Assure that the students understand the need for a good solution before applying the solution.

We consider this pattern a true invariant, as independent of the domain a specific pattern should only be applied after all relevant information has been gathered and analysed.

It has to become the “natural way” for students to follow the order implied in patterns. They have to focus first on the context, the problem, and the forces of a pattern, even if the solution is the first thing which is visually attracting their attention. This implicitly includes that the needed information is available to the students. If examples are used for learning, teach the students to first answer the question of why a pattern is used in this example, and only then to look at how it is applied or implemented. An awareness of the consequences of not respecting this order can be created by exposing them to the Experience of Problems (Experience of Problems).

To improve the consequences of Context, Problem and Consequences First (Context, Problem and Consequences First), students should actively discuss the problem and context. Gestwicki and Sun state that “a discussion of the domain-specific problem leads to the justification of the design pattern”. Different Active Learning patterns can be used to realize this . However, teachers should be able to facilitate such a discussion. They are responsible for keeping the focus of the discussion on the important parts and preventing the discussion from drifting in unwanted directions. This requires teachers to have a good knowledge of the design patterns — especially of the addressed problems, the forces, and the consequences as well as possible variations. The set-up for such a discussion should also take social aspects into account: it is important to create and maintain an open and constructive atmosphere and aggressive or attacking behaviour should not be tolerated.

Gestwicki and Sun also emphasize that the first and most important part of applying a pattern is a good understanding of the context and the problem. The focus should therefore be put on these parts while learning design patterns as well as for the application of design patterns to solve real problems. Wallingford also describes an approach where the first step is to analyse the problem at hand and the context before actually applying the pattern. Be aware that there are often different levels of problems, ranging from abstract problems like “I need to decouple these two system parts” to concrete problems like “I need to be able to add a new implementation of this algorithm easily”. A discussion of the problem part should respect and reflect these levels.

In one exercise during the course on Patterns & Frameworks at the Hogeschool Utrecht students were required to study the Facade pattern from the GoF-book and were then asked to summarize this pattern. Most students started to describe the solution, but when asked which problems the pattern addresses the answers became more vague and divergent. So the students got a second exercise (which was the implementation of Context, Problem and Consequences First (Context, Problem and Consequences First)). They were given 3 short problem descriptions and had to decide for which of these they would apply the Facade (Facade) pattern. They were encouraged to use the GoF-book and online sources to substantiate their decision. The students had to work first in groups of two and then in bigger groups of four (an application of Student Design Sprint (Student Design Sprint) in order to improve the communication between the students). Finally, one student of each group was randomly chosen to present the groups argumentation for which problem description the Facade (Facade) pattern can be applied (and why!) and for which not (and why not!), hereby making use of the pedagogical pattern Shot Gun Seminar (Shot Gun Seminar). These argumentations were then subject to discussion of the whole class. This lead to a better awareness of the problem and contexts which were addressed, but also the consequences of applying the pattern. In a follow-up exercise the students then had to implement the pattern. This way all parts of the pattern were covered, and they were covered in the correct order.

Kevlin Henney, an independent consultant and co-author of Pattern-Oriented Software Architecture Volume 5 (POSA5), makes use of this pattern by giving a lot of examples involving consideration of context, forces and a clear understanding of the problem when teaching design patterns.

The authors of Head First Design Patterns. emphasize the analysis of the problem, the context, the forces and the consequences of applying a pattern prior to the real application as basis for a grounded decision for or against a pattern application.

The assignments given to students in courses on software architecture at the University of Vienna often include the need for determining the applicability of specific architectural patterns before their application. This includes a discussion of the context, problem and consequences sections of the patterns to be applied.