This chapter is from the book
This chapter is from the book
This chapter is from the book
An Observation About Using Design Patterns
When people begin to look at design patterns, they often focus on the solutions the patterns offer. This seems reasonable because design patterns are advertised as providing good solutions to the problems at hand.
However, this is starting at the wrong end. Before trying to apply a solution to a problem, you should understand the problem. Taking an approach that looks for where you can apply patterns tells you what to do but not when to use it or why to do it.
I find it much more useful to focus on the context of the pattern—the problem it is trying to solve. This lets me know the when and the why. It is more consistent with the philosophy of Alexander’s patterns: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem....”3
What I have done so far in this chapter is a case in point. What is the problem being solved by the Bridge pattern?
The Bridge pattern is useful when you have an abstraction that has different implementations. It allows the abstraction and the implementation to vary independently of each other.
The characteristics of the problem fit this nicely. I can know that I ought to be using the Bridge pattern even though I do not know yet how to implement it. Allowing for the abstraction to vary independently from the implementation would mean I could add new abstractions without changing my implementations and vice versa.
The current solution does not allow for this independent variation. I can see that it would be better if I could create an implementation that would allow for this.
The bottom line: It is very important to realize that, without even knowing how to implement the Bridge pattern, you can determine that it would be useful in this situation. You will find that this is generally true of design patterns. That is, you can identify when to apply them to your problem domain before knowing exactly how to implement them.