Design Patterns Explained

3O8 Part V1 • Endings and Beginnings
The next step in
commonality/
variability analysis
But please keep learning patterns. Read the literature. Patterns provide
the backdrop for discussions about lessons learned in analysis
and design. They give a team of developers a common vocabulary
for discussing a problem. They enable you to incorporate
best-practice approaches into your code.
Decomposing a Problem Domain
into Responsibilities
Commonality/variability analysis identifies my conceptual view
(the commonality) and my implementation view (each particular
variation). If I consider just the commonalities and the objects that
use them, I can think about the problems in a different way— a
decomposition of responsibilities.
In the Bridge pattern, for example, the pattern says to look at my
problem domain as being composed of two different types of entities
(abstractions and implementations). I therefore do not need to be
limited by just doing object-oriented decomposition (that is, decomposing
my problem domain into objects), I can also try decomposing
my problem domain into responsibilities, if that is easier for me to
do. I can then define the obje cts that I require to implement these
responsibilities (ending up with object decomposition).
This is just an extension of the rule I stated earlier that designers
should not worry about how to instantiate objects until after they
know all of the objects they need. That rule can be viewed as a
decomposing the problem domain into two parts:
• Which objects are needed
• How these objects are instantiated
Specific patterns often give us assistance in thinking about how to
decompose responsibilities. For example, the Decorator pattern
gives me a way to combine objects flexibly if I decompose my prob-