CCP

Common Closure Principle

“The classes in a component should be closed together against the same kinds of changes. A change that affects a component affects all the classes in that component and no other components.” – Robert C. Martin

This is the Single Responsibility Principle for Components. Gather into components those classes that change for the same reasons and at the same times.

When to use

When deciding which classes belong in the same package/library/microservice.

Why it matters

** deployability**: If I change a business rule, I only want to redeploy ONE component, not five.
Maintainability: Related code is physically close.

Signs of Violation

“Shotgun Surgery” at the package level: A single requirement change forces you to update and release 5 different npm packages.

Explanation

Problem

If classes that change together are in different components, you have to release all those components every time.

Solution

Group them together. If two classes are tightly coupled and always change together, they belong in the same package.

Real world analogy

A toolbox again. If you change the size of screws, you probably need to change the screwdrivers. It makes sense to sell them as a “Screwdriver Set” rather than selling the handles in one store and the tips in another.

Pros and Cons

Pros	Cons
Easier releases Validation is localized	Components might become larger

Comparison

SRP: CCP is SRP applied to packages.
REP: REP groups for reuse; CCP groups for maintenance.They often fight (CCP wants larger components, REP wants smaller ones).

CCP