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 they are advertised as providing good solutions to the problems at hand.

However, this is starting at the wrong end. When you learn patterns by focusing on the solutions they present, it makes it hard to determine the situations in which a pattern applies. This only tells us 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 the environment, and then describes the core of the solution to that problem …”^[3]

^[3] Alexander, C., Ishikawa, S., Silverstein, M., A Pattern Language: Towns/Buildings/Construction, New York: Oxford University Press, 1977, p. x.

What I have done here 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.

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.