SOLID — Interface Segregation Principle: Worked examples

Before we start, we reuse one tool from the parent — the forced-dependency count. Let me re-earn every symbol so a newcomer can read line one.

The bar chart below shows exactly what these two numbers look like. Each implementer is a column. Below the dashed yellow line at $m = 3$ we colour the green portion (methods genuinely used, $u_{i}$ ) and stack the red portion on top (the forced gap $m - u_{i}$ ). The total red height across all columns is $F_{fat}$ . The blue column beside each one is the segregated world: only the green used-portion remains, no red at all — that is $F_{seg} = 0$ . Look at how the two single-purpose machines carry tall red blocks while the all-capable AllInOne has none: fat interfaces punish the narrow clients.

Figure — SOLID — Interface Segregation Principle

The scenario matrix

Every problem this topic can throw at you falls into one of these cells. The worked examples below are tagged with the cell they cover. Two boundary cells (Z and Y) are the truly degenerate inputs — no implementers and no methods — and we discuss them right after the table.

Cell	Case class	Trigger to watch for	Example
A	Classic fat split	one interface, mixed roles, a stub/throw	Ex 1
B	Multi-role class	a class that legitimately needs many roles	Ex 2
C	Zero forced weight (already good)	$F = 0$ before you touch it — do nothing	Ex 3
D	Degenerate / single implementer	$n = 1$ , is splitting worth it?	Ex 4
E	Over-splitting trap (exam twist)	methods always used together	Ex 5
F	Real-world word problem	narrative, you extract $m, n, u_{i}$	Ex 6
G	Limiting behaviour	$m$ grows, or $u_{i} \to m$ , or $u_{i} \to 1$	Ex 7
H	Interaction with LSP	a throw hides an ISP+LSP double fault	Ex 8
Z	No implementers ( $n = 0$ )	interface exists but nothing implements it	below
Y	Empty interface ( $m = 0$ )	a marker interface with no methods	below

The diagram below lays out the eight main cells as a grid so you can see the space you're covering rather than read it as a list — colour marks whether each cell ends at $F = 0$ already (green) or needs a fix (red).

We now walk every remaining cell.

Worked Examples

Example 1 — Cell A: the classic fat split

Worked example Statement

interface Worker { void work(); void eat(); }
class RobotWorker implements Worker {
    public void work() { /* assemble */ }
    public void eat()  { throw new UnsupportedOperationException(); }
}

There is one more class, HumanWorker, that uses both methods. Compute $F$ before segregation, then after, and explain the code change.

Forecast: guess how many forced dependencies exist right now. (Two? Zero?)

Identify $m, n, u_{i}$ . $m = 2$ (work, eat). $n = 2$ implementers. Human uses both: $u_{1} = 2$ . Robot only works: $u_{2} = 1$ . Why this step? $F$ is defined purely from these three numbers, so we extract them first.
Compute the fat cost. $F_{fat} = (2 - 2) + (2 - 1) = 0 + 1 = 1$ . Why this step? The single forced dependency is exactly the robot's fake eat() — the number pins the smell to one method.
Segregate by role. Split into Workable { work() } and Feedable { eat() }. Human implements both; Robot implements only Workable. Why this step? Grouping by "who uses it together" removes the robot's obligation to eat().
Compute the segregated cost. Now robot's interface has $m = 1$ , $u = 1$ ; human's roles each match its needs. $F_{seg} = 0$ . Why this step? Confirms the split actually removed the forced weight (didn't just move it).

Verify: $F_{fat} = 1$ , $F_{seg} = 0$ , so ISP removed $1$ forced dependency. The removed unit corresponds to the one UnsupportedOperationException we deleted — units match (1 forced method = 1 stub).

Example 2 — Cell B: a class that needs many roles

Extract numbers. $m = 3$ . $n = 3$ . Uses: AllInOne $u_{1} = 3$ , OldPrinter $u_{2} = 1$ , Scanjet $u_{3} = 1$ . Why this step? Same recipe — the formula only cares about these counts.
Fat cost. $F_{fat} = (3 - 3) + (3 - 1) + (3 - 1) = 0 + 2 + 2 = 4$ . Why this step? Notice AllInOne contributes $0$ — a class using everything is never over-served. All forced weight comes from the single-purpose machines. This is the exact scenario drawn in figure s01.
Segregate. Printer{print}, Scanner{scan}, Fax{fax}. AllInOne implements Printer, Scanner, Fax (multiple small interfaces — this is allowed and encouraged). Why this step? A class needing many roles simply composes them; ISP never forbids implementing several interfaces.
Segregated cost. Each class now implements exactly the roles it uses: $F_{seg} = 0$ . Why this step? Verifies composition removed all $4$ forced units.

Verify: $F_{fat} = 4$ , $F_{seg} = 0$ ; win $= 4$ . The multi-role class added $0$ to the fat cost, confirming that fat interfaces punish the narrow implementers, not the broad one.

Example 3 — Cell C: already good, $F = 0$ , do nothing

Worked example Statement

interface Comparable<T> { int compareTo(T o); }

Three classes implement it — Money, Date, Version — and every one uses compareTo. Should you split it?

Forecast: how many interfaces after applying ISP?

Numbers. $m = 1$ , $n = 3$ , every $u_{i} = 1$ . Why this step? A one-method interface cannot over-serve anyone.
Cost. $F_{fat} = (1 - 1) \times 3 = 0$ . Why this step? $F = 0$ means there is nothing to fix — ISP is already satisfied.
Decision. Leave it. Splitting a single cohesive method would create an empty win and hurt readability. Why this step? ISP is a diagnosis tool, not a mandate to shred every interface.

Verify: $F = 0$ before and after; interfaces after $= 1$ . Sanity check: you cannot make $F$ negative, so $0$ is optimal — nothing to do.

Example 4 — Cell D: degenerate single implementer ( $n = 1$ )

Compute now. $F = (4 - 4) = 0$ . Why this step? With one all-using client, there is currently no forced weight.
Ask the future question. ISP is also about anticipated clients. If a read-only ReportViewer will soon need only load, it would be forced into save/migrate/backup. Why this step? $F$ measures the present; ISP reasoning also weighs likely new clients — a degenerate present can hide a fat future.
Judgment. If a narrow client is realistically coming, pre-split into Reader{load} and Writer{save;migrate;backup}. If not, leave it. Why this step? ISP balances real cohesion against speculative splitting — don't split for imaginary clients.

Verify: present $F = 0$ ; hypothetical read-only client would raise $F$ to $(4 - 1) = 3$ . The number quantifies exactly the future risk (3 forced methods), guiding the decision.

Example 5 — Cell E: the over-splitting trap (exam twist)

Worked example Statement

interface Stream { int read(); void write(int b); }

Every client that reads also writes (it's a bidirectional socket). A student "applies ISP" by splitting into Reader{read} and Writer{write}. Is this correct? Compute $F$ both ways.

Forecast: does splitting reduce $F$ here, or is it pointless?

Before. $m = 2$ , say $n = 2$ clients, both use both methods, so $u_{1} = 2$ and $u_{2} = 2$ . Then $F_{fat} = (2 - 2) + (2 - 2) = 0 + 0 = 0$ . Why this step? Cohesive methods used together give $F_{fat} = 0$ already — there was never any forced weight to remove.
After naive split. Each client must now depend on both Reader and Writer anyway; nothing was over-served, so $F_{seg}$ stays $0$ but you've added an interface. Why this step? Splitting cohesive methods creates "interface explosion" with no $F$ improvement — the classic ISP anti-pattern.
Correct call. Keep Stream as one role, because cohesion, not minimal size, is the goal (see the parent mistake box). Relate to Cohesion and Coupling: high method cohesion ⇒ keep together. Why this step? ISP splits by client role, not by counting methods.

Verify: $F_{fat} = 0$ and $F_{seg} = 0$ — the split changed nothing measurable but added $1$ interface. Zero benefit, positive cost ⇒ over-splitting is objectively worse.

Example 6 — Cell F: real-world word problem

Read off $u_{i}$ . Basic $u_{1} = 1$ , Plus $u_{2} = 2$ , Elite $u_{3} = 4$ . $m = 4$ , $n = 3$ . Why this step? Translate the story into the three numbers the formula needs.
Fat cost. $F_{fat} = (4 - 1) + (4 - 2) + (4 - 4) = 3 + 2 + 0 = 5$ . Why this step? The 3 tells us Basic is dragged into 3 unused abilities — the biggest sufferer, as the narrowest client always is.
Segregate by tier need. Checkin{checkIn}, Pool{usePool}, Trainer{bookTrainer}, Sauna{useSauna}. Basic implements Checkin; Plus implements Checkin, Pool; Elite implements all four. Why this step? Each tier composes exactly the roles it sells.
Segregated cost. $F_{seg} = 0$ . Why this step? Confirms all 5 forced units removed.

Verify: $F_{fat} = 5$ , $F_{seg} = 0$ , eliminated $= 5$ . Units: 5 forced methods removed across 3 classes; Basic accounted for 3 of them, matching "narrowest client suffers most."

Example 7 — Cell G: limiting behaviour

Substitute. $F = \sum_{i = 1}^{n} (m - 1) = n (m - 1)$ . Why this step? Every term is identical, so the sum is just $n$ copies of $(m - 1)$ .
Limit as $m \to \infty$ . $F \approx n m$ grows linearly in $m$ — add one method, add $n$ forced dependencies. Why this step? Shows why fat interfaces get catastrophically worse in big systems: cost scales with both size and client count.
Opposite limit. If instead every $u_{i} = m$ (everyone uses everything), $F = \sum (m - m) = 0$ regardless of $m$ . Why this step? Confirms the degenerate "cohesive giant" boundary — big is fine iff every client uses all of it.

Verify: For $m = 3, n = 2, u_{i} = 1$ : $F = n (m - 1) = 2 \cdot 2 = 4$ , matching Example 2's fat count. For $u_{i} = m$ : $F = 0$ for any $m$ . Both boundary formulas check out.

Example 8 — Cell H: ISP meets the Liskov Substitution Principle

Worked example Statement

interface Bird { void fly(); void eat(); }
class Penguin implements Bird {
    public void fly() { throw new UnsupportedOperationException(); }
    public void eat() { /* real */ }
}

Name both principles broken and give the ISP-clean redesign.

Forecast: two principles are violated here — which two?

ISP diagnosis. Penguin uses $1$ of $2$ methods; $F_{fat} = (2 - 1) = 1$ forced dependency (fly), flagged by the throwing stub. Why this step? The stub is the ISP fingerprint — a forced method the client can't honestly provide.
LSP diagnosis. Any code holding a Bird may call fly() expecting flight; a Penguin crashes it. That breaks substitutability — the Penguin does not honour the Bird promise. Why this step? A throwing stub is simultaneously an ISP smell and a Liskov Substitution Principle violation — one bad line, two broken principles.
Redesign. Split into Eater{eat} and Flyer{fly}. Penguin implements Eater; a Sparrow implements Eater, Flyer. Why this step? Removing fly from the penguin's contract fixes both faults at once, giving $F_{seg} = 0$ and restoring substitutability.

Verify: before $F_{fat} = 1$ (one stub); after $F_{seg} = 0$ . Both ISP (forced method gone) and LSP (no lying override) restored — one redesign, two checks pass.

Recall Self-test across the matrix

Which cell has $F = 0$ and still might warrant splitting? ::: Cell D — single implementer, $F = 0$ now, but a likely narrow future client justifies pre-splitting. In Example 7, what is $F$ when every client uses exactly one of $m$ methods? ::: $n (m - 1)$ . Why does over-splitting (Cell E) not improve $F$ ? ::: The methods are cohesive (always used together), so no client was ever over-served — $F$ was already $0$ . Which class contributes $0$ to $F_{fat}$ in every example? ::: The one that uses all $m$ methods ( $u_{i} = m$ ). What is $F$ for an interface with no implementers ( $n = 0$ ) or no methods ( $m = 0$ )? ::: $0$ in both cases — an empty sum, or all-zero terms.

Connections

SOLID — Interface Segregation Principle — this page is its worked-example deep dive.
SOLID — Single Responsibility Principle — the " $F = 0$ but maybe split" call (Cell D) is really SRP-style reasoning about future change.
SOLID — Liskov Substitution Principle — Example 8 shows the throw-stub double fault.
SOLID — Dependency Inversion Principle — the small role interfaces we produced are the ideal abstractions to depend on.
Cohesion and Coupling — Cell E is decided entirely by method cohesion.
Design Patterns — Adapter — when a legacy fat class must fit a segregated interface, an adapter bridges the gap.