If you know a software architect, a professor who teaches SOLID, or anyone who takes design principles seriously β I'd appreciate you sharing this with them.
Two companion papers established the structural biconditional between ISP and per-client DIP (paper 1) and proved that Martin's packaging principles are jointly unsatisfiable for the resulting configuration β specifically, CCP and REP cannot both be satisfied (paper 2).
This third paper applies the Independent Variation Principle (IVP) to the same five-element setup and obtains two results from a single application.
Result 1: DIP β ISP, formalized in IVP terms
The first companion paper proved the structural biconditional: ISP β per-client DIP. This paper formalizes the forward direction (DIP implies ISP) in IVP terms. Each interface slice shares its client's change-driver assignment. The IVP biconditional (elements co-reside iff they share driver assignments) closes the proof: the slices are disjoint because the clients belong to different modules. IVP adds formalism to one direction of a valid structural biconditional; it is useful here but not indispensable.
Result 2: A unique modularization
This is where IVP is essential.
Five elements: provider A, clients B and C, interface slices I_B and I_C. Three distinct driver assignments: {Ξ³_ord} for B and I_B, {Ξ³_rep} for C and I_C, {Ξ³_ord, Ξ³_rep, Ξ³_impl} for A.
IVP-3 (elements with different driver assignments cannot co-reside) and IVP-4 (elements with identical driver assignments must co-reside) together admit exactly one partition:
- Module B: B and I_B (both driven by Ξ³_ord)
- Module C: C and I_C (both driven by Ξ³_rep)
- Module A: A alone (composite: Ξ³_ord, Ξ³_rep, Ξ³_impl)
Each interface slice lives with its client β not as a design preference, but as a consequence of the axioms applied to the causal structure of change.
What this settles
The packaging paper showed that eight principles β DIP, ISP, and six packaging principles (REP, CCP, CRP, ADP, SDP, SAP) β give three incompatible answers (with client, with provider, own module) and no meta-criterion for choosing. IVP eliminates two of the three by deriving the answer from Ξ.
If two engineers disagree about where I_B belongs, the disagreement traces to a disagreement about Ξ β about what can cause I_B to require modification. That is an epistemic question about the system, not a design preference. IVP converts a judgment call into a falsifiable claim.
What IVP's placement produces
The paper verifies that the unique IVP partition delivers:
- Change isolation: a change to Ξ³_ord modifies Module B (containing B and I_B) and nothing else. Module C is untouched.
- No shotgun surgery: the pathology that scattered interface placement creates is eliminated by construction.
- Acyclic dependencies in the providerβclient subgraph: A depends on Module B and Module C (for the interface specifications it implements). Neither client module depends on A. No cycle exists in this subgraph.
- Independent deployability: each module can be released independently.
The paper
"The Interface Segregation Principle Is a Corollary of the Dependency Inversion Principle --- A Formal Proof via the Independent Variation Principle"
- Paper: https://zenodo.org/records/19641242
- Companion 1 (ISP = DIP, structural): https://zenodo.org/records/19633560
- Companion 2 (packaging unsatisfiability): https://zenodo.org/records/19636635
- Companion 1 dev.to article: SOLID: ISP Is Just DIP Applied Twice
- Companion 2 dev.to article: SOLID's Packaging Principles Are Jointly Unsatisfiable
The first paper showed ISP and DIP produce the same structure. The second showed SOLID's principles can't agree on where to put it. This one shows IVP can.
If you think the unique partition is wrong β that I_B belongs somewhere other than with B β I'd like to hear the argument. What change driver does I_B respond to, if not B's?
