What are the three component cohesion principles (REP, CCP, CRP) described by Robert C. Martin, and what does each one say about which code belongs together in a releasable component?

## What a "component" means here In this vocabulary a **component** is *the smallest unit that can be independently released and deployed*. Concretely: a `.jar`, a `.dll`, an npm package, a Python wheel, a Go module, a NuGet package, a shared library, or — at bigger grain — a deployable service. The key property is not physical file format but **independent release with a version number**. Everything below is about deciding *which classes/files live inside one such unit*. Cohesion here means **"belonging together"**, and Robert C. Martin ("Uncle Bob") formulated three principles that answer that question. They come from *Agile Software Development* (2002) and *Clean Architecture* (2017). --- ## 1. REP — Reuse/Release Equivalence Principle > *"The granule of reuse is the granule of release."* If you want other people (or other teams, or your own other projects) to **reuse** your code, that code must be **released**: given a version number, published to some repository, accompanied by release notes describing what changed, and tracked over time so consumers can decide when to upgrade. Two consequences: - **You cannot reuse something smaller than what you release.** If a library is released as one versioned artifact, consumers take all of it or none of it. So the artifact's contents must form a coherent, explainable whole — "a theme, a purpose, a story" — otherwise the release notes make no sense ("v2.4: added an HTTP retry policy and a matrix determinant solver" is a smell). - **Release infrastructure is a first-class requirement**, not paperwork. No version numbers, no changelog, no notifications → no safe reuse, because a consumer can never tell whether upgrading will break them. REP is weakly stated (it says what happens when you get it wrong, more than what to do), but violating it is glaring: consumers get surprised by breaking changes, or a "utils" grab-bag forces everyone to re-qualify unrelated code on every release. --- ## 2. CCP — Common Closure Principle > *"Gather into components those classes that change for the same reasons and at the same times. Separate those classes that change for different reasons and at different times."* This is the **Single Responsibility Principle raised to component scale**. SRP says a class should have one reason to change; CCP says a *component* should have one reason to change. The motivation is **maintenance economics**, not elegance. When a requirement changes, you would much rather have that change confined to **one** component — which means one artifact to re-validate, re-version, re-release, and redeploy — than smeared across seven. Every extra component touched by a typical change multiplies build/test/release/redeploy work and the chance of a version-skew mistake. CCP also connects to the **Open/Closed Principle**: since you can't make code closed against *all* changes, you choose which changes to be closed against. CCP groups things so that the classes *not* closed against the same kind of change sit together, so the leakage is contained inside one component's boundary. Practical signal: look at your version-control history. If two files almost always change in the same commit, CCP says they probably belong in the same component. If a component's files never change together, it is probably two components. --- ## 3. CRP — Common Reuse Principle > *"Don't force users of a component to depend on things they don't need."* This is the **Interface Segregation Principle raised to component scale**. Classes that are almost always used together should live together; classes that are used independently should be split apart. The cost CRP protects you from is the cost of a **dependency you didn't want**. When component A depends on component B, A depends on *all of B* — including the parts A never calls. If an unused class in B changes, B gets a new version; A's team then has to (at minimum) revalidate, recompile, retest and redeploy A, even though nothing A uses actually changed. On a strongly-versioned platform it can be worse: transitive constraints, diamond conflicts, larger binaries, extra transitive third-party dependencies, and a bigger attack surface from code you never execute. So CRP is as much about **what to keep OUT** of a component as about what to put in. Its stronger reading: *an unnecessary dependency edge is a real, recurring cost — pay attention to which classes drag which other classes along.* --- ## The tension between them - **REP and CCP are inclusive**: they make components larger (more reusable stories together; more change-mates together). - **CRP is exclusive**: it makes components smaller (throw out anything not reused together). A good architect deliberately sits somewhere inside that triangle and **moves over time**: | You over-emphasise… | You suffer… | |---|---| | REP + CCP (ignore CRP) | consumers get too many spurious releases/rebuilds from changes they don't care about | | REP + CRP (ignore CCP) | one requirement change hits many components — release/deploy churn | | CCP + CRP (ignore REP) | fine-grained, well-factored components that are hard for anyone else to consume safely | Early in a project, developability dominates — CCP wins, components are coarse, reuse is secondary. As a system matures and outside consumers appear, the pressure moves toward REP/CRP and components get split. **The partitioning is expected to change with the project's maturity — it is not a one-time decision.** --- ## Common confusions to avoid - These are **cohesion** principles (what goes inside a component). The separate **coupling** principles — ADP (no dependency cycles), SDP (depend in the direction of stability), SAP (stable components should be abstract) — govern the edges *between* components. Interviewers often check that you don't mix the two families. - Cohesion here is *not* the classic LCOM-style intra-class cohesion metric; it's about change and reuse patterns of whole artifacts. - "Component" is not necessarily "microservice", though the principles apply to service boundaries too.