Part Overview
In this part, I work through another case study. In this case study, I will consider the requirements for the problem one at a time, rather than specifying every requirement up front. I will describe a system that is currently working when a new requirement comes in that forces me to find the best way to modify the code. I will use this process to present a few new design patterns—one for each new requirement.
Chapter Discusses These Topics 14 The Strategy pattern: How to handle varying algorithms and business rules. 15 The Decorator pattern: How to dynamically add behavior before or after an object's current behavior. 16 The Singleton pattern and the Double-Checked Locking pattern: How to ensure not more than one instance of a class is ever instantiated, even in a multithreaded environment. 17 The Observer pattern: How to let one part of a system know when an event takes place in another. 18 The Template Method pattern: What to do when you have different cases that use essentially the same procedure, but their steps must be implemented in slightly different ways. 19 The Factory Method pattern: How to defer instantiation of particular objects to derived classes. 20 The Analysis Matrix: How to track multiple variations that are present in your problem domain and map them into patterns. When a new requirement is introduced to the problem, I will look at the different alternatives I could use, such as:
Using switches in the code
Specialization with inheritance
Encapsulating what varies and containing it or using a reference to it
By looking at these alternatives, I show that there are similarities among many of the patterns: often, different patterns will approach handling variation and new requirements in a similar fashion.