Experience of Benefits/alx
Experience of Benefits | |
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), Experienced Advantage (Experienced Advantage)
Giving the students the Experience of Problems (Experience of Problems) helps in intrinsically motivating them to do something about these problems. Naturally, these problems often can be solved in many different ways and students often tend to apply the most straight-forward approach to solving them which often is not the best possible one. Their motivation to apply a pattern for solving the problem is initially often only extrinsically motivated by the teacher.
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 intrinsic motivation of the students to use patterns outside of the educational setting.
After students had the Experience of Problems (Experience of Problems), 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 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 benefits 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 Experience of Problems (Experience of Problems), but both patterns cover different aspects. While Experience of Problems (Experience of Problems) shows what happens when the problem is not addressed, Experience of Benefits (Experience of Benefits) reveals what happens when the problem is appropriately addressed and solved, using the pattern selected as Best Fitting Pattern Choice (Best Fitting Pattern Choice). While the main focus should be put on the benefits, the liabilities also need to be addressed.
Experience of Benefits (Experience of Benefits) 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, 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 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[4].
The implementation described by Cinn´eide and Tynan focusses more on the advantages a pattern can offer during its implementation[5]. 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 states that students should experience the full lifecycle of a pattern so that they really appreciate the benefits[6]. 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 the 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´eide and Tynan used this pattern[5]. 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 Experience of Problems (Experience of Problems) and Experience of Benefits (Experience of Benefits) in one exercise.
References
- ↑ 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.
- ↑ 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.
- ↑ 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.
- ↑ Gestwicki, P., & Sun, F. S. (2008). Teaching design patterns through computer game development. Journal on Educational Resources in Computing (JERIC), 8(1), 2.
- ↑ 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.
- ↑ 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..