The Common Closure Principle

Let’s finish the week off with another Component Principle: The Common Closure Principle. We have already explored the Reuse/Release Equivalence Principle.

In the .NET world, Component Principles are guidelines on how to group classes into Visual Studio projects. The projects get built into deployable EXE or DLL files.

Uncle Bob’s book ‘Clean Architecture’ defines the Common Closure Principle (CCP) as 

“Gather into components those classes that change for the same reasons and at the same times. Separate into different components, those classes that change at different times and for different reasons.” 

This definition is similar to the Single Responsibility Principle (SRP), concerned with constructing cohesive classes—grouping functions and data that belong together because they change together. The CCP is the SRP for components.

That makes sense; when we must change our program, we should prefer to make modifications in one component rather than five. In this way, we would only need to redeploy one component, not five. 

More critical even than DevOps deployment concerns, it’s confusing to work with code that naturally belongs in one place yet is strewn across the codebase. If two classes always change together, they belong in the same component. 

The CCP helps us give good names to our projects and components. In .NET, that means we have a tidy solution that is understandable and makes sense. We can find what we were searching for with ease. If we have a hodgepodge of classes with no overarching purpose sitting together in the same project, what do we call such a project? The opposite is also true—having projects with descriptive names yet containing classes that don’t seem to belong is equally frustrating for a developer.

To sum up, Cohesion exists at many levels. The general rule then becomes to group those things that change for the same reason while separating those things that change for different reasons.