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 objects 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 problem domain into the main set of responsibilities I always use (the ConcreteComponent) and the variations I optionally have—my decorators. Strategies decompose my problem into an object that uses rules and the rules themselves.