SOLID: Formal proof shows DIP, ISP and classic packaging principles can be mutually unsatisfiable
A formal proof argues SOLID’s DIP and ISP conflict with packaging rules like REP and CCP, showing multi-client providers cannot be packaged to satisfy them all.
The SOLID design rules that many architects teach as complementary guidance are not merely incomplete trade-offs in practice — according to a formal proof announced in a recent paper, they can be mutually unsatisfiable for routine object‑oriented dependency patterns. The paper, titled "SOLID: Where Do Client-Owned Interfaces Live? DIP, ISP, and the Packaging Principles," examines a minimal but common configuration and demonstrates that widely‑cited packaging principles (as described by Martin) cannot in general be applied simultaneously; for an important class of provider‑to‑multiple‑clients dependencies, enforcing one principle forces violation of another. That result reframes how architects, educators, and teams should reason about SOLID and packaging guidance when designing package boundaries and modular systems.
The minimal configuration that exposes the tension
The paper studies a compact, representative scenario: a provider element A that implements two separate interfaces (I_B and I_C), and two clients, B and C, that each depend solely on their respective interfaces. This five‑element arrangement — provider, two client‑specific interfaces, and two client modules — is presented as the smallest non‑trivial DIP/ISP‑compliant configuration where the question of package placement becomes meaningful. The authors point out that this pattern is routine in object‑oriented codebases: providers exposing client‑owned interfaces and multiple consumers needing only narrow contracts.
Although there are 52 possible ways to partition these five elements into packages, the paper uses Martin’s familiar set of eight principles (the Dependency Inversion Principle and the Interface Segregation Principle alongside six packaging principles — REP, CCP, CRP, ADP, SDP, SAP) to prune the space of allowable partitions. The surprising outcome is that the familiar principles do not converge on a single, consistent packaging in this modest example.
Why REP and CCP cannot both hold for the pattern
At the heart of the formal result is a direct conflict between two packaging principles that practitioners often treat as compatible: the Common Closure Principle (CCP) and the Reuse/Release Equivalence Principle (REP). CCP says that classes that change for the same reasons should live in the same package; REP requires packages to be viable units of reuse — consumers should not be forced to take things they do not use.
When DIP is used with an ownership interpretation, the interface I_B is considered to change for the same reasons as client B. Under CCP, that co‑change relation pulls I_B into the same package as B. But A must implement I_B, and REP then requires that A’s package depend on whichever package contains I_B; if I_B is packaged with B, A must take a dependency on B even though it uses only the interface and not the client implementation. That dependency relationship makes A’s package absorb unintended elements or the consumer take on unnecessary dependencies, violating REP. The paper presents this as a two‑step proof and notes the reasoning generalizes to any system in which a provider serves two or more clients through client‑specific interfaces: no partitioning satisfies both CCP and REP in that configuration.
The purported packaging “triangle” lacks a navigable interior
Robert C. Martin’s packaging principles are often presented as a tension triangle among CCP, CRP (Common Reuse Principle), and REP — a three‑way pull in which architects choose which vertex to relax. The paper challenges that characterization: the triangle metaphor suggests a manageable trade‑off space with a navigable interior, but for the studied configuration the interior is empty.
Removing REP from the triangle does not help: CCP and CRP together still produce no satisfying partitions for the arrangement under study. Dropping CRP while keeping CCP and REP likewise leaves the original CCP/REP conflict unresolved. Only by dropping CCP do any candidate partitions survive, and even then the remaining partitions are undistinguished by the remaining principles; multiple partitions persist with no principle able to select among them. In short, two of the triangle’s three escape routes lead to dead ends, and the triangle offers no principled way to choose a package layout for this common pattern.
How DIP and ISP figure into the contradiction
The paper also examines where the Dependency Inversion Principle (DIP) and the Interface Segregation Principle (ISP) fit into this landscape. It references an earlier companion paper that showed ISP can be derived as a corollary of DIP at the class level (establishing which elements — such as client‑specific interfaces — should exist). That companion result settles the identity of elements but not their package placement.
Reintroducing DIP into the packaging analysis does not resolve the inconsistency. Different readings of DIP produce different effects: a co‑location reading (that related abstractions and owners should be packaged together) contradicts REP; an examples‑based reading undermines ISP; and an ownership reading adds no additional constraint on package placement. Only an interpretation of DIP that stays silent about package boundaries leaves some partitions available. The net effect is that DIP and ISP restrict what elements must exist but do not rescue the packaging principles from internal contradiction when applied to multi‑client provider patterns.
Every recommended placement is both defensible and indictable
Practically, architects typically consider three natural placements for a client‑owned interface: place the interface with the client, place it with the provider, or give it its own package. The paper argues that each placement can be supported by one or more of the packaging principles and simultaneously condemned by others, all within the same theoretical framework. In other words, the principles do not simply fail to agree; they actively argue against each candidate they seem to recommend.
When a principle recommends co‑locating an interface with the client (CCP), REP will often object; when REP suggests a different partition, CCP or CRP may object. As a result, the packaging rules self‑defeat: they supply principled reasons for each choice and principled reasons to reject the very same choice. That internal inconsistency undermines the expectation that the packaging principles provide a coherent method for selecting package boundaries in these scenarios.
Practical implications for architects, educators, and teams
If no packaging satisfies all of the considered principles, then any system containing a multi‑client provider configuration will violate at least one principle at every point in its history. This conclusion has several consequences for practice:
-
Architectural decision‑making: Treating the packaging principles as an oracle that yields a single correct partition is misguided for systems that include multi‑client providers. Architects must acknowledge that packages will necessarily trade off different principles and that some violations are unavoidable rather than symptomatic of poor skill or oversight.
-
Teaching and mentorship: Students who learn SOLID and Martin’s packaging principles as a coherent methodology risk two incorrect inferences when they inevitably cannot satisfy every principle: either they blame their own competence, or they conclude the principles are mere heuristics. The paper contends that neither inference captures the true situation: the underlying principles, in aggregate, can be collectively unsatisfiable for common dependency patterns.
-
Refactoring and technical debt: The concept of technical debt presumes a principled ideal state to return to. For packaging, if no single ideal partition exists that satisfies all principles, then the notion of a debt‑free packaging ideal becomes illusory. Teams should therefore reframe packaging decisions as trade‑offs to be managed rather than as deviations from a uniquely correct architecture to be “paid down.”
- Tooling and automation: Static analysis or automated packaging suggesters that encode these principles as hard constraints will encounter impossible cases where no valid configuration exists. Such tools should instead enable designers to express preferences and trade‑offs, and to flag unavoidable principle violations with contextual explanations.
Industry context: where this matters across ecosystems
Although the paper frames the issue in terms of object‑oriented package boundaries and classical SOLID rhetoric, the implications reach across software ecosystems. Packaging choices influence API design, component reuse, dependency graphs in build and CI systems, modularization strategies in large codebases, and dependency management in platforms ranging from developer tools and automation frameworks to security libraries and enterprise CRM/integration layers. Any environment that separates abstractions from implementations and that allows providers to serve multiple consumers through tailored interfaces will encounter the same packaging tensions the paper formalizes.
This means that teams building microservices, developer SDKs, plugin systems, and automation connectors should be conscious that strict adherence to all packaging principles is unattainable in some commonplace patterns. The result encourages cross‑team discussions about which principles to privilege based on business and maintenance priorities rather than assuming a principled single right answer.
What the formal proof establishes and what it leaves open
The core formal claim is precise and technical: for the studied five‑element configuration (a provider implementing two client‑specific interfaces and two clients depending on those interfaces), CCP and REP are jointly unsatisfiable; no partition of those elements into packages satisfies both principles simultaneously. The proof is said to be two steps and generalizes to any provider that serves two or more clients with client‑specific interfaces.
The paper does not stop at the CCP/REP contradiction; it analyzes the tension triangle (CCP, CRP, REP) and shows that removing one of the conditions does not restore satisfiability in most cases, and that only by dropping CCP do any candidate partitions survive — but then multiple undistinguished partitions remain. The companion result that ISP follows from DIP at the class level is cited to clarify that while ISP and DIP determine which abstractions should exist, they do not settle how to distribute those abstractions across package boundaries.
What the paper intentionally does not do — and therefore what readers should not infer — is propose a universally applicable, prescriptive replacement for the packaging principles. Instead, it frames packaging rules as potentially conflicting constraints and invites practitioners and researchers to reexamine the conceptual status of these principles: are they binding constraints, soft preferences, or context‑dependent heuristics?
Questions the result raises for practice and pedagogy
The paper closes with a pointed set of questions intended to provoke discussion. Can anyone produce a packaging of a multi‑client provider configuration that satisfies CCP and REP simultaneously? If one takes CCP not as a hard constraint but as a preference, what does it mean to call something a "principle" if it can always be overridden by judgment? Those questions force a reappraisal of how software engineering principles are taught and applied: whether they should be cast as axioms, rules of thumb, or context‑sensitive policies.
For teams, the practical upshot is to make packaging rationales explicit: when a package boundary is chosen, document which principles were prioritized, why they were favored, and which principles were knowingly sacrificed. That practice turns inevitable violations into deliberate trade‑offs that can be reassessed as system requirements and usage patterns evolve.
Broader implications for developers, businesses, and research
Beyond individual design choices, the proof has broader theoretical and organizational implications. For developers and architecture teams, it suggests shifting from a search for a perfect partition toward an engineering mindset that manages competing constraints. For businesses, it implies that contractual or organizational structures that assume a unique “right” modularization may misalign with technical realities; governance and code ownership policies should allow for principled trade‑offs and evolution.
For academic and applied research, the paper opens a path for formalizing other interactions among design principles. If common principles can be shown to be collectively unsatisfiable in simple patterns, researchers should explore which combinations remain consistent under different formalizations, how to prioritize principles based on measurable system qualities (e.g., coupling, churn, reuse), and how to encode preferences into tool support for packaging decisions.
A companion research agenda also emerges around pedagogy: educators might present SOLID and the packaging principles not as a checklist guaranteeing correctness but as a landscape of constraints and trade‑offs, illustrated by formal counterexamples like the one in this paper. That reframing would better prepare students for the realities of industrial codebases where multiple good reasons pull a design in different directions.
The paper titled "SOLID: Where Do Client-Owned Interfaces Live? DIP, ISP, and the Packaging Principles" adds to a growing conversation about the limits of rule‑based design guidance. Its formal demonstration that familiar packaging principles can be internally contradictory for plausible configurations compels a reconsideration of how those principles are used and taught. Practitioners should take away two concrete points: first, that the existence of client‑owned interfaces (a corollary of DIP/ISP) is distinct from the question of where to place them in package boundaries; and second, that packaging guidance must be treated as a framework for trade‑offs rather than as a source of universally satisfiable constraints.
If teams, educators, and tool builders accept that some violations are unavoidable, the next step is practical: define clear, context‑sensitive strategies for prioritizing principles, make trade‑offs explicit in architecture decisions, and evolve tooling to surface and explain unavoidable conflicts rather than enforcing brittle hard constraints. The formal proof provides the theoretical grounding for that pragmatic shift and invites both researchers and practitioners to propose refined principles, preference systems, or decision frameworks that better reflect the complexity of real‑world modularization.
