What does the Common Reuse Principle (CRP), one of Robert C. Martin's component-cohesion principles, state, and what problem is it meant to prevent?

## Vocabulary first **Component** here means a *unit of deployment and release*: the smallest thing you can independently version, publish and consume — a jar, a NuGet/npm package, a Python wheel, a Go module, a shared library, a Maven artifact. It is not "a class" and not merely "a folder" or "a namespace". A namespace is a *naming* device; a component is a *shipping* device. That distinction is the entire point of CRP, because you can only take a dependency on a whole component — you cannot depend on 3 of its 40 classes. **Cohesion** means "the degree to which the things inside a unit belong together". At class level we ask whether methods belong in one class; CRP asks the same question one level up: which classes belong in one *shipped* unit. ## The principle, stated two ways 1. **Positive form:** *The classes in a component are reused together. If you reuse one of the classes in a component, you reuse them all.* 2. **Negative (operational) form:** *Don't force users of a component to depend on things they don't need.* The negative form is the one you actually apply. Positive-form statements tell you what may be grouped; the negative form tells you what must be **split apart**. CRP is a *splitter* — it pushes component boundaries to be smaller and more numerous. (Its siblings REP and CCP are *grouper* forces that push components to be larger; see the tension-triangle question.) ## Why does an unused class cost anything? The naive objection is "if I never call that class, it costs me nothing." It costs plenty, because a dependency is not just a call: - **Release coupling.** When the component publishes 2.4.0 because an unrelated subsystem changed, *you* are the one who must decide whether to upgrade, re-run your test suite, re-certify, and redeploy. Even choosing to stay on 2.3.0 is a cost: you now diverge, and later security patches will land on top of changes you didn't want. - **Transitive dependency load.** The unused half of the component drags in *its* dependencies. Pull in a component for its JSON reader and you may also inherit an XML parser, a logging framework, and a reflection library. - **Version-conflict surface.** Those transitive dependencies collide with other components' choices (the "diamond"/version-skew problem). More unused code means more chances of an unresolvable constraint. - **Security and compliance surface.** A CVE in the unused subsystem is still a CVE in your dependency tree; scanners flag it, auditors ask about it, and you must upgrade or justify. - **Build and artifact size.** Longer compiles, bigger images/bundles, slower cold starts, more classes to load. - **Cognitive and API surface.** Every consumer's IDE autocomplete, documentation and mental model now include things irrelevant to them. So "depending on" ≠ "calling". Depending on a component means *being coupled to its release cycle and its dependency closure*. ## How you decide what is "used together" The empirical test is: look at the actual consumers. If most consumers use classes {A,B,C} and a disjoint set of consumers uses {X,Y,Z}, and almost no one uses both, the component is violating CRP and should become two components. If instead nearly every consumer that touches A also touches B and C, they belong together. A useful structural heuristic: classes bound by strong static relationships — inheritance, an interface and its main implementations, a class and its parameter/return types, a builder and the thing it builds — are almost always used together, so they should live in the same component. Splitting *those* apart is the opposite failure: it forces every consumer to assemble a jigsaw of packages before anything works. ## Classic violations - A `common`/`utils`/`shared` component that accumulates string helpers, date math, an HTTP client, a retry policy, and a feature-flag reader. Nobody uses all of it; everybody depends on all of it. - A monolithic cloud SDK where using the object-store client makes you carry clients for forty other services. (Vendors eventually split these into per-service artifacts precisely because of CRP pressure.) - A "kitchen-sink" framework artifact instead of core/web/data/test artifacts. ## Classic over-corrections CRP taken to the extreme yields dozens of one-class packages: an exploded dependency graph, version-lockstep pain, publishing overhead, and discoverability problems. CRP is one force among three, not an absolute. ## How to phrase it in an interview "CRP is ISP at component granularity. ISP says don't make a client depend on methods it doesn't use; CRP says don't make a client depend on *classes* it doesn't use — and the reason is that a component is the unit of release, so an unused class still couples you to its releases, its transitive dependencies and its vulnerability surface."