Keep It Simple/alx

Keep It Simple
Contributors	Christian Köppe
Last modification	June 5, 2017
Source	Köppe (2011); Köppe (2013)
Pattern formats	OPR Alexandrian
Usability
Learning domain
Stakeholders

Also Known As: Simplicity Above Patterns (Simplicity Above Patterns)

Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. -Albert Einstein

When patterns are taught to students, then it usually is also expected that the students apply them in some assignments or exercises. The implementation of patterns nearly always increases the overall complexity in some way, either by adding additional elements to a design or different activities to a certain process.

***

While learning patterns students want to show that they understand the patterns by implementing as many of them as possible. Most often this adds unnecessary complexity without adding value.

The application of a design pattern often adds complexity to the design of a software system in terms of extra classes, methods or relations between objects and classes. But if applied in a correct way, design patterns can add value through improving the quality of a systems’ design in respect of non-functional requirements. However, a software designer has to make sensible decisions on when to use a design pattern and how to implement it. These decisions include trade-offs between the added complexity and the improved quality.

Exhaustive Use. Students often seem to skip this trade-off and decide to use a pattern even if it is not necessary. This is probably related to their experiences in other courses, where they are required to show that they understood all concepts and techniques taught to them by applying them. When being taught Enterprise JavaBeans (EJB), they probably have to implement all sorts of EJB’s. When introduced to specific UML diagrams, they probably are requested to make use of all of them. Exposing students to an increasing number of patterns seems to correlate with the amount of pattern implementations.

Decreased Necessity. With design patterns it is a different story. A typical larger assignment in a course which also teaches design patterns often does require the use of some of the learned design patterns, but most probably not all of them

Complex vs. Straightforward. In some cases a problem or requirement could also be implemented — or designed — using a straightforward solution. Most pattern beginners tend to choose for still applying the pattern, thereby adding unnecessary complexity.

***

Therefore: Motivate the students to always give a rationale for all design patterns they have used. Make sure that they only apply a design pattern when they have not only examined the design problem at hand, but also the consequences of applying the pattern. The application of the pattern should add value to the overall design.

This pattern is considered as true invariant for the teaching of patterns of all domains, as the tendency of applying patterns excessively after being introduced to them can be found in nearly all domains.

To ensure that the students always have a rationale let them study the Context, Problem and Consequences First (Context, Problem and Consequences First). A good understanding of the problem, the context, and possible consequences form the basis for the tradeoffs which are part of the decision on when to use a pattern and when not. It has to be ensured that students understand that not applying the solution of a pattern if this is not appropriate is a good practice and higher valued than the simple application of the patterns.

While discussing the trade-offs, experience shows that the students put less emphasis on general principles of a good system design (like low coupling, high cohesion, etc.), so you have to emphasize that the students apply a Principle-Supporting Pattern Usage (Principle-Supporting Pattern Usage). Generally, make sure that they understand that the goal is not to apply as many design patterns as possible, but to create a good design that implements the requirements and that design patterns can — and should — help to do this.

Additional to an oral discussion of the trade-offs it could also be asked from the students to give a written explanation of the rationale as part of an exercise or assignment, if time and other conditions allow this. This also would include the application of Prefer Writing (Prefer Writing).

We were delivering an earlier version of the course “Patterns and Frameworks”, which was not yet based on this pattern language. During the final presentations of the project, one of the students gave as a rationale why he used a specific design pattern that ’they had to use a pattern and that he chose that one’. When asked if he really had a design problem and if he understands the consequences of applying this pattern, he had no answers. After starting to work with this pattern language, the students were required to present their solutions to the whole class and give a rationale for each pattern they were using. The other students were encouraged to ask questions about the design decisions made and also to state if they have possible alternative solutions. This way it became natural to the students to provide a rationale for all their decisions and trade-offs, which lead to decreased complexity of their designs.

In the book Head First Design Patterns the authors state that it is more important to keep the design as simple as possible and not to blindly apply design patterns. They explicitly state that the most simple and straightforward solution should always be considered too, and that sometimes this is sufficient. They also explicitly suggest to remove a pattern from the design if this improves the simplicity of it.