The structure of a class is fixed when the class is compiled. However, there are occasions when an operation may need to take on different characteristics at run time as circumstances vary. In other words, it might be necessary that the method call MyObject.DoSomething behaves differently at different times.
This chapter discusses techniques that make variations in a method’s behaviour possible at run time, even after compilation, either through the use of inheritance structures or through delegation.
The first technique, the Template Method pattern, breaks a method into several steps and then allows subclasses to override these individual steps as needed.
The second technique, the Strategy pattern, delegates the operation to different subclasses within an associated hierarchy depending on what behaviour is required.
The third technique, the Player–Role pattern, overlaps in several ways with the Strategy pattern, though its application is more specific. All three these techniques help to produce code that is robust and relatively easy to modify in the face of changing requirements.
Variable steps within a set sequence
Sometimes a class needs a method with a particular sequence of steps but the details of the steps may vary depending on circumstances. Let’s say that the local music school needs a simple information kiosk for the summer school it is organising. When someone requests information about the summer school, the program must give a welcome message, details of the venue, and the date for paying the deposit. The summer school will offer tuition for a number of different instruments and the details of the venue will vary from instrument to instrument.The information kiosk must be available before all the details of the summer school are finalised, and so the software must be highly modifiable in case tuition subsequently becomes available for additional instruments.
Based on this set of requirements, our program design must accommodate several factors:
- It will always perform a known and fixed sequence of operations (display the welcome, the tuition venue and the date for the deposit)
- Details of some of the operations vary under different circumstances (different venues for different instruments)
- There is the possibility of adding additional cases (for possible tuition in other instruments) and,
- We need default operations for cases where no special operation applies.
This was only the introduction to this chapter, make sure you download the full chapter text (~37 pages) along with the source code!
