Published January 16, 2022
by Doug Klugh

Encapsulating Functionality

Design components by grouping classes together that change for the same reason, while separating those that change for different reasons.  This will help minimize the number of components that change when requirements change.  Since the classes within a component all have the same Single Responsibility, they all serve the same actor.  Therefore, these classes are closed to all but that one responsibility and to the needs of every other actor.  So when requirements change, we will know which components are affected and which are not.

The Common Closure Principle can be combined with the Dependency Inversion Principle to facilitate independent deployability.  As illustrated below in figure 1, packaging a base class into a component with those classes that use it separates them from those classes that implement that base class.  Then any other component with its own implementation can plug right into that first component.

In this example, the base class Switchable is packaged with the Switch class that uses it, then the Lamp class that implements the Switchable class is packaged in a separate component.  Now any other "switchable" appliance (fan, radio, etc.) can be plugged into the first component without any changes to that component.  Then you only need to deploy that one component with the fan, radio, or whatever.  A change to either component will not require both to be deployed — only the one that was changed.  Wallah, independent deployability!