Part V: Handling Variations with Design Patterns

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.