Get the responsibilities assigned to the right classes
The key to a flexible object-oriented system is to get the responsibilities assigned to the right analysis classes.
This definition of the approach is often quoted, yet to achieve the goal seems to require a skill that is more art than science. It is best to start with an abstract approach, considering each entity in the domain model in isolation. What is this entity? What does it mean to be one of these things? Follow this by asking how any other entity may want to use one of these things. One problem that is frequently encountered is that many domain entities in the ‘real world’ exist as pieces of paper, and a qualified person (i.e. one who knows what needs to be done) does all the smart stuff that is associated with the entity. Our aim is to associate the right ‘smart stuff’ with the right entity.
Collaboration diagrams giving typical uses of domain objects, or specific uses when within the context of a system under development, can aid in identifying cases where responsibilities are not in the right place. An entity that collaborates with three others has a look that ‘feels right’. Other numbers are suspect, but not necessarily incorrect. The relationships in a collaboration diagram can be investigated by assigning role names to them. Consider each object in isolation. What would it expect of any entities that were acting in the named role for each association? Do the role names look right from its point of view? Do the responsibilities of the collaborating objects fill those expected for the named role?
Diagnostic: When each change in requirements results in changes to several parts of the code, it is likely either that we don’t have the responsibilities in the right place, or we are failing to apply VariationBehindInterface to cut down on the ripple effect. The latter cause can be distinguished where the changes are as a result of the primary change to functionality rather than being part of the primary change to functionality.