Published January 15, 2022
by Doug Klugh

Promoting Mobility

Design components to be large enough to justify the cost of managing the release cycle.  These management activities include assigning release numbers, maintaining release notes with features and known issues, keeping track of dates, committing to grandfather old versions, etc.  Others cannot reuse your components without them.  Considering the time and effort these activities require, it is unlikely you will be able to manage a large number of components.  Better to plan a small number of strategic components that conform to the other Principles of Component Cohesion.

Designing Strategic Components

One of the challenges in designing strategic components is knowing what to put in them.  Luckily, there are two other Principles of Component Cohesion that help resolve that challenge.  The Common Closure Principle (CCP) tells us that classes that change for the same reason should be grouped together in the same component.  Does this sound like the Single Responsibility Principle (SRP)?  It should.  While the CCP provides cohesion for classes, the SRP provides cohesion for functions. 

The Common Reuse Principle (CRP) tells us to create components where if one class in the component is used, they’re all used.  This principle should sound like the Interface Segregation Principle (ISP) — for the same reason.  While the CRP cohesively binds classes, the ISP provides further cohesion for functions. 

These principles, along with the Principles of Component Coupling, provide methods for deciding how to design our components — so they align with and support other engineering principles and patterns.

What is a Component?

A component is a collection of classes encapsulated within an independently deployable library, such as a jar, gem, or DLL.  These libraries are independently deployable when a change to one does not cause others to be recompiled or redeployed.  The key to developing independently deployable components is to manage dependencies.  For example, changes to an application do not require that framework components be recompiled or redeployed.  Applications depend on frameworks.  Frameworks do not depend on applications.  If developed correctly, you should be able to swap out components during a normal business day, with all users hammering away at your system, with zero downtime.

« Classes are a necessary but insufficient vehicle for decomposition. »

- Grady Booch

Modular Design

Imagine building a large software system out of many small and simple classes.  If you only follow the Single Responsibility Principle, this is exactly what you will end up with.  So, we need a way to group classes together into larger modules.  Components provide a way to encapsulate related classes into larger chunks.  The trick is determining which classes should be grouped together within a component — which is resolved by the Principles of Component Cohesion.  Then the next challenge is managing the dependencies between components — which is solved by the Principles of Component Coupling.

« It's like building a sandcastle from individual grains of sand. »

- Bob Martin