Experienced Advantage/alx

From Open Pattern Repository for Online Learning Systems
Jump to navigation Jump to search


Experienced Advantage
Contributors Christian Köppe
Last modification May 17, 2017
Source Köppe (2011)[1][2]; Köppe (2013)[3]
Pattern formats OPR Alexandrian
Usability
Learning domain
Stakeholders

Also Known As: Rewarding Sweets (Rewarding Sweets), Experience of Benefits (Experience of Benefits)


Experienced Advantage-alx.png
Let’s face it, a nice creamy chocolate cake does a lot for a lot of people; it does for me.
-Audrey Hepburn


You want to show students that patterns are really helpful.

***

It is hard for students to see the advantages generated by correctly applied pattern solutions if they are only told to them. This has negative impact on the motivation of the students to use patterns outside of the educational environment.


After students understood the Experienced Problem (Experienced Problem), they start to understand why a solution is needed to solve a problem. But purely applying a pattern is only part of the story.


Shortened Software Lifecycle. The correct appliance of patterns creates a resulting context, which offers in some cases advantages (e.g. better modifiability). Even if the students apply a pattern correct to reach this, they often miss the part that they really get advantage out of this, as the student projects often stop right before getting to this phase of the lifecycle.


Curricula. It seems that computer science and software engineering curricula still focus mainly on the activities prior the deployment and maintenance phases in the lifecycle of software systems.


Belief. Purely hearing from the teacher that a solution is a good solution because it offers some advantages which actually can’t be experienced by the students themselves, requires a high belief of the students in what the teacher says. Some students experienced that some teachers don’t have reasonable arguments for why some things are good and have to be done in the way the teacher wants to. Their belief is therefore dependent on their previous experiences with specific teachers.


Motivation. If students do not believe in the advantages of applying patterns, then they probably get their motivation purely out of the grading or teacher’s feedback they receive. If this this is the only thing of value for them it is likely that they do not apply patterns again or that they still apply them in an incorrect way. This extrinsic motivation is therefore not very helpful in teaching design patterns.


***

Therefore: Give the students rewarding sweets — something of value or satisfaction for the students — by letting them experience the advantages one gets after or during the correct application of a pattern first hand.


In the domain of software design the benefits of applying patterns can — and should — be demonstrated to students. But in other domains this is not always possible, as the real implementation of a pattern solution might be out-scoping the teaching context (e.g. when trying to show the benefit of Alexander’s Towns (Towns) pattern). Therefore this pattern is considered as an invariant in the context of software design patterns.


This pattern is closely related to Experienced Problem (Experienced Problem), but both patterns cover different aspects. While Experienced Problem (Experienced Problem) shows what happens when the problem is not addressed, Experienced Advantage (Experienced Advantage) reveals what happens when the problem is appropriately addressed and solved, using the pattern selected as Best Fitting Pattern Choice (Best Fitting Pattern Choice).


Experienced Advantage (Experienced Advantage) can be realized using an existing implementation of a pattern solution. This implementation can then be used as basis for a follow-up assignment, where the focus is led on making use of the benefits of the correct pattern application. This way the students can experience the advantage themselves. However, the implementation can be of different origins: as Pattern Implementation Matters (Pattern Implementation Matters), the students may already have implemented a pattern in the correct way themselves. But also a solution can be given to the students by the teacher which includes a correct implementation of a pattern.


In some cases it might be sufficient to only discuss the benefits. For example, Gestwicki and Sun[4] introduced the State (State) design pattern by comparing it with earlier designs made by the students and discussing the shortcomings of these designs and the possible benefits from the application of the State (State) pattern.


The implementation described in Cinnéide & Tynan[5] focuses more on the advantages a pattern can offer during its implementation. They used a problem-based approach in order to let the students “appreciate the flexibility provided by the pattern". The students had to implement a solution without using a specific pattern and then implement it again using this pattern, showing them that using the pattern was the more easy way.


Warren [6]states that students should experience the full lifecycle of a pattern so that they really appreciate the benefits. Using this pattern reduces the need for projects which cover the full software lifecycle, as it simulates the phases which can not be included in student projects due to time constraints. This increases the awareness of the consequences of applying patterns and also offers a way for introducing activities to the curriculum which are related to phases in the later part of the software development lifecycle.


In one exercise the students were asked to implement a small cook-administration system. All cooks made use of one of a few preparation strategies, and the students were asked to use the Strategy (Strategy) pattern to realize this. In a follow-up assignment they were asked to add another strategy and assign it to one of cooks. Furthermore they had to describe how difficult it was to realize this and how long it took them. Their answers showed that they experienced it as an easy task which was implemented in a few minutes. So they had a noticeable benefit after the application of the Strategy (Strategy) pattern.


Cinnéide and Tynan[5] used this pattern. The students were offered two solutions, one implemented in an ad-hoc way and one using the Observer (Observer) design pattern. They were required to add a new view for both solutions. This way they were able to experience the simplicity offered by the solution which used the Observer (Observer) pattern instead of just reading about it, which increases the understanding of the advantages of applying patterns. As stated earlier, this implementation combines Experienced Problem (Experienced Problem) and Experienced Advantage (Experienced Advantage) in one exercise.


References

  1. Patlet 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.
  2. Pattern first 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.
  3. 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.
  4. Gestwicki, P., & Sun, F. S. (2008). Teaching design patterns through computer game development. Journal on Educational Resources in Computing (JERIC), 8(1), 2.
  5. 5.0 5.1 Cinnéide, M. Ó., & Tynan, R. (2004). A problem-based approach to teaching design patterns. In ACM SIGCSE Bulletin (Vol. 36, No. 4, pp. 80-82). ACM.
  6. 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..