Exercises — SOLID — Interface Segregation Principle

(b). Option (a) is the Single Responsibility Principle, (c) is the Dependency Inversion Principle, and (d) is the Liskov Substitution Principle. ISP is specifically about what a client is forced to depend on.

The smell is the ==throw new UnsupportedOperationException()== inside methods scan and fax. OldPrinter was forced to implement abilities it does not have. Those two stubbed methods are the fingerprint of a fat interface (Machine) that bundled unrelated roles — two forced dependencies, exactly the orange arrows from the figure above.

1→B, 2→C, 3→A. Client is the subtle one: it is not only the code that calls a method. The implementing class is also a client of the interface, because it too is "forced to depend" on every declared method.

Split by role — one interface per cohesive capability:

interface Printer { void print(Doc d); }
interface Scanner { void scan(Doc d); }
interface Fax     { void fax(Doc d); }
 
class OldPrinter implements Printer {
    public void print(Doc d) { /* real work */ }
}
class AllInOne implements Printer, Scanner, Fax {
    public void print(Doc d) { ... }
    public void scan(Doc d)  { ... }
    public void fax(Doc d)   { ... }
}

Why: OldPrinter's contract is now honest — it advertises only print. A class needing several roles simply implements several small interfaces (composition of roles). This is the right-hand side of the figure above.

Here $m=3$. Plug each implementer in: $F_{\text{fat}}=(3-1)+(3-1)+(3-2)+(3-3)+(3-3)=2+2+1+0+0=5.$ So the fat interface forces 5 dead method dependencies. After perfect segregation each implementer pulls in exactly its $u_i$, so $F_{\text{seg}}=0$ — those 5 vanish.

The stacked bar chart below makes this concrete: for each implementer the teal block is the methods it uses and the orange block on top is the forced gap $m-u_i$. The total orange height across all five bars is $F_{\text{fat}}=5$.

It should depend only on ==Feedable==. Why the bug disappears: a RobotWorker implements only Workable, so it is not a Feedable. The scheduler cannot even reference a robot — the type system rejects scheduler.feed(robot) at compile time. The old bug (robot.eat() throwing at runtime) is now impossible to write.

It breaks two:

• ISP, because the class was forced to depend on a method (scan) it does not use — the stub is the very symptom ISP warns about.
• LSP, because a caller holding a Machine reference expects scan() to work. Substituting an OldPrinter for a general Machine breaks that expectation at runtime. The subtype does not honour the supertype's contract.

"It compiles" is not the same as "it is substitutable." A compile-time stub is a runtime bomb. The correct fix is to remove scan from the interface OldPrinter implements — i.e. segregate.

This is primarily an ISP problem, and not necessarily an SRP problem.

• SRP asks: does the class have more than one reason to change? Possibly not — "managing an account" can be argued as one responsibility.
• ISP asks: are clients forced to depend on methods they don't use? Yes. The login screen only needs checkPassword, yet it depends on a type that also declares banUser and generateInvoice. Change generateInvoice's signature and the login screen recompiles for no reason.

Fix: split into role interfaces Authenticatable, Moderatable, Billable, each handed to the client that needs it. This shows ISP is "SRP for interfaces"—about callers, not about the class's internal reasons to change.

Forced dependencies: $F_{\text{fat}}=(4-4)+(4-1)+(4-1)+(4-2)=0+3+3+2=8.$ Total declared obligations $=m\cdot n=4\cdot 4=16$. Fraction that was dead weight: $\frac{F_{\text{fat}}}{m\cdot n}=\frac{8}{16}=0.5=50\%.$ Half of every "must implement" here was a lie removed by ISP.

Why every term is $\ge 0$ (the $m\ge u_i$ fact): $u_i$ counts methods the implementer uses out of the interface. You cannot use a method that is not there — the interface only offers $m$ of them — so at most $u_i=m$, i.e. $u_i\le m$ for every $i$. Hence each gap $m-u_i$ is never negative: forced dependencies can only add, never subtract.

Use the Adapter pattern. Define the segregated role interface, then wrap the fat legacy class:

interface Summariser {
    String headline();
    int total();
}
 
class ReporterAdapter implements Summariser {
    private final LegacyReporter legacy;
    ReporterAdapter(LegacyReporter legacy) { this.legacy = legacy; }
    public String headline() { return legacy.buildFullReport().getTitle(); }
    public int total()       { return legacy.computeGrandTotal(); }
}

Why this synthesises ISP + Adapter: new clients depend only on the thin Summariser (ISP satisfied), while the adapter absorbs the fat legacy API behind the scenes. The adapter is precisely "a translator between a segregated interface and an un-segregatable class."

DIP says high-level modules should depend on abstractions. The quality of that abstraction matters:

• A fat abstraction re-imports all the coupling DIP was trying to break — you inverted the dependency arrow but still depend on 12 methods, so any of the 12 changing ripples up.
• A small role interface exposes only what the high-level module needs, so the inverted dependency is minimal and stable.

In short: ISP makes the abstractions DIP depends on thin and stable. ISP + DIP together give you both "point at an interface" and "point at a tiny one."

Under perfect segregation each implementer $i$ implements exactly the interfaces whose methods it uses, so it is forced to supply exactly $u_i$ methods and no more. Its forced (unused) count is $u_i-u_i=0$. Summing: $F_{\text{seg}}={\sum }_{i=1}^{n}0=0.$ Since every term of $F_{\text{fat}}={\sum }_i(m-u_i)$ has $m\ge u_i$ (you cannot use more methods than exist), each term is $\ge 0$, so $F_{\text{fat}}\ge 0=F_{\text{seg}}$. Equality ($F_{\text{fat}}=0$) holds only when every implementer already uses all $m$ methods ($u_i=m$ for all $i$) — i.e. the interface was never fat to begin with, so there is nothing to segregate.

Define $\Delta F$ = (forced dependencies after the addition) − (before). The new method raises $m$ by 1, and every implementer must now supply it — but only $k$ of them use it. The other $n-k$ gain one forced dependency each, while the $k$ that use it gain zero. Therefore $\Delta F=n-k.$ Interpretation: one line added to a fat interface imposes $n-k$ new dead implementations — the cost of a change grows with the number of unrelated implementers. With segregation the new method lives in its own role interface that only the $k$ needers implement, so $\Delta F=0$. This is the mechanical reason "a fat interface has many reasons to change / many things to break."

Decision rule: split when there exists at least one real client that uses one method but is forced into the other. Cohesion is measured by how clients use the methods together, not by how related they sound.

• Read-only files are a concrete client that needs read() but must not be forced to implement write(). That existence proof means the methods are not cohesive for all clients → split into Readable and Writable.
• A read-write file simply implements both (class RWFile implements Readable, Writable).

So the second colleague is wrong because a divergent client exists. Had every stream always been read-write, keeping Stream would be correct (over-splitting is the L2 trap).

• (a) $n=0$ (vacuous): the sum ${\sum }_{i=1}^0$ has no terms, so by the convention that an empty sum equals $0$, $F_{\text{fat}}=0$. An interface nobody implements forces nothing — it is harmless (though possibly dead code). This vacuous truth matters: "there are no implementers to force" is why the metric is zero, not because usage was perfect.
• (b) $m=0$: each term is $0-u_i$, but $u_i\le m=0$ forces $u_i=0$, so every term is $0$ → $F_{\text{fat}}=0$. A marker interface with no methods can force nothing.
• (c) all $u_i=m$: every term $m-m=0$ → $F_{\text{fat}}=0$. The interface is perfectly cohesive; ISP has nothing to fix.
• (d) all $u_i=0$: every term $m-0=m$ → $F_{\text{fat}}=n\cdot m$, the maximum. Every implementer is dead weight in every method — the worst possible fat interface, where nobody uses anything they're forced to implement.

• ISP → SRP: same "keep it small" spirit, but SRP judges a class's reasons to change, ISP judges what a caller is forced to depend on (Exercise 3.2).
• ISP → LSP: a forced stub that throws is exactly the LSP-breaking substitution (Exercise 3.1).
• ISP → DIP: thin role interfaces are the best abstractions to invert onto (Exercise 4.2).
• ISP → Cohesion: segregation groups methods by cohesive role, raising cohesion and cutting accidental coupling (L2 trap).

• L1–L2: you can name ISP and mechanically split a fat interface.
• L3: you can tell ISP from SRP and spot the LSP break in a stub.
• L4: you combine ISP with Adapter and DIP.
• L5: you can prove the win formula's bounds and defend every degenerate and vacuous case.