Published January 27, 2022
by Doug Klugh

Minimize Dependencies

Design components by ensuring that if one class in the component is used, they’re all used.  This will prevent dependent components from having to be needlessly retested and redeployed because a class, that it does not use, was changed within that component.  This aligns with the Law of Demeter by promoting interactions only with closely related classes and by limiting knowledge of other parts of the system.  This also helps to deodorize the smell of Immobility.

Unwanted Dependencies

In figure 1 below, component A depends upon component B because the two classes in A depend upon a class in B.  However, there are three other classes in component B that A does not depend upon.

When one of those other three classes in component B changes, it causes B to be re-versioned and re-released.  And even though component A does not depend upon those other classes, A will need to be retested and redeployed — and maybe even reversioned.

Figure 1 - Component Dependency
Promoting Mobility

This is one scenario the Common Reuse Principle aims to avoid.  Users of your component should not have to needlessly retest and redeploy their components because you changed a class in your component that they do not use.

The reverse is also true.  Your team should only depend upon components in which you depend upon all the classes within that component.