How do the Common Closure Principle, the Single Responsibility Principle, and the Open-Closed Principle relate to each other?

## The three statements - **SRP - Single Responsibility Principle**: a class should have one, and only one, reason to change. The sharper modern phrasing: a module should be responsible to one and only one *actor* (one group of stakeholders that requests changes). Two actors requesting changes to the same class means their changes collide. - **OCP - Open-Closed Principle**: software entities should be open for extension but closed for modification. New behaviour should be addable without editing the existing, already-tested code - normally by depending on an abstraction and adding a new implementation behind it. - **CCP - Common Closure Principle**: gather into a component the classes that change for the same reasons and at the same times. Separate those that change for different reasons at different times. ## How they line up | Principle | Unit | Question it answers | |---|---|---| | SRP | class | How many reasons may this class have to change? (one) | | CCP | component | How many reasons may this component have to change? (one) | | OCP | any | Can the change be absorbed by adding rather than editing? | SRP -> CCP is a **change of granularity**: same idea, bigger unit. That is why CCP is often introduced as 'SRP for components'. CCP adds one thing SRP does not stress: **timing**. Two classes may arguably change for different reasons, but if they invariably change in the same release, CCP puts them together anyway, because the operational cost is what CCP is optimising. OCP -> CCP is a **fallback relationship**. The word *closure* is taken directly from OCP. Ideally a component is closed against a change (no edit needed). Reality: you can only be closed against *anticipated* kinds of change, and abstracting against every possible change is over-engineering. So CCP says: for the changes you did not or could not close against, ensure the edits are contained in one component - closed *within* a boundary rather than closed *out* entirely. ## A worked chain Suppose tax rules change every quarter. 1. **OCP attempt**: define a `TaxRule` abstraction so a new jurisdiction's rule is a new implementation - added, not edited. Change absorbed by extension. 2. **What OCP cannot close**: the shape of the abstraction itself. If the tax authority introduces a concept the interface cannot express, you must modify. 3. **CCP then applies**: keep the rule implementations, the rule interface, and their configuration in **one** component, so that unavoidable modification means one component rebuilt and redeployed, not five. 4. **SRP inside it**: within that component, no single class should serve both the tax-authority actor and, say, the reporting actor. ## Common confusions - **SRP is not 'a class does one thing'.** It is about *one reason to change / one actor*. A class can perform several coordinated steps for one actor and still satisfy SRP. - **OCP does not forbid ever editing code.** It says prefer designs where common, anticipated variation is additive. Blanket abstraction 'in case' is speculative generality. - **CCP is not 'put everything together'.** The Common Reuse Principle counterbalances it by ejecting classes consumers don't use. - **CCP is not a SOLID principle.** SOLID (SRP, OCP, LSP, ISP, DIP) governs classes; the component principles are a separate set - cohesion (REP, CCP, CRP) and coupling (ADP, SDP, SAP). Mixing the two families up is a common interview slip. ## Cousins worth naming The class-level principles have component-level analogues: SRP ~ CCP, and ISP (don't force clients to depend on methods they don't use) ~ CRP (don't force consumers to depend on classes they don't use). Noticing that symmetry is a strong signal in an interview.