Common Closure Principle

No Change
adopt
First Added:June 24, 2026 Updated: July 2, 2026

Common Closure Principle is a technique we adopt in the garden.

Summary

When to use: Evaluate on a project when the capability clearly fits the requirement.

When to skip: When a simpler alternative already covers the need.

Details

Component Cohesion Context

CCP is one of three classic component cohesion principles (Robert C. Martin). Siblings are Reuse-Release Equivalence Principle (REP) and Common Reuse Principle (CRP). Teams often trade them off: tight CCP reduces release coupling; tight CRP favors convenience imports.

PrincipleGist
REPRelease components as a unit when reused (Reuse-Release Equivalence Principle)
CCPGroup classes that change together
CRPGroup classes reused together (Common Reuse Principle)

SRP and OCP at Component Level

Class-level principleComponent-level counterpart
Single Responsibility Principle (one reason to change)CCP (one change driver per component)
Open-Closed Principle (closed to unrelated change)CCP splits (unrelated concerns in separate deployables)

Practical Signs

SignalLikely fix
Unrelated teams block on one library versionSplit by change axis (CCP)
Frequent releases touch files that never co-changeMove outliers to another package
“Kitchen sink” shared modulePeel off domains with different owners

Common Failure Modes

  • common or utils packages that accumulate every cross-cutting helper
  • Microservices split by technical layer (all SQL in one service) instead of change driver
  • Monorepo packages named by org chart that do not match deploy or change patterns
  • Confusing CCP with “put everything in one repo” (version and release boundaries still matter)

Related Garden Items