DEV Community

Cover image for Where Do Interfaces Live? IVP Answers What SOLID Cannot
Yannick Loth
Yannick Loth

Posted on

Where Do Interfaces Live? IVP Answers What SOLID Cannot

#architecture #solidprinciples #softwareengineering #independentvariationprinciple

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"

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?

Top comments (0)