Noesis
2.2.7 · D1Design Principles

Foundations — SOLID — Interface Segregation Principle

1,438 words7 min read↑ Back to topic

Before you can appreciate the parent note, you need to earn every word it throws at you: interface, method, client, implement, contract, role, cohesion, and the little formula . We build each one from nothing, with a picture, and only then use it.

1. What is a method?

A method is a single named action a piece of code can perform. Think of one labelled button.

WHAT the picture shows: a button engraved with a verb. WHY we need it: ISP is entirely about which actions a piece of code is forced to carry. If we can't point at one action, we can't argue about it.

Figure — SOLID — Interface Segregation Principle

2. What is an interface?

Now collect several buttons onto one panel and label the whole panel. That panel is an interface.

WHY the topic needs it: ISP's whole complaint is that we sometimes make these panels too big — a remote with 80 buttons when a task needs 4.

Figure — SOLID — Interface Segregation Principle
  • A "fat" interface ::: a panel with many buttons, only some of which any given user presses.
  • Why "contract"? ::: because implementing the interface is a promise every listed method really works.

3. Implement — signing the contract

A class implements an interface when it actually builds working wiring behind every button on the panel.

  • What does a class do to a fake button it can't support? ::: it stubs it — an empty method or one that throws an error (a lie in the type system).

4. Client — who is depending on whom?

This word is the trickiest, so we picture it directly.

Figure — SOLID — Interface Segregation Principle
  • The caller depends on the interface to ::: know which actions it may request.
  • The implementer depends on the interface to ::: know which actions it must supply.

5. Role and cohesion — the natural cut lines

If a fat panel is the problem, where do we cut it? Along roles, held together by cohesion.

6. The symbols in the formula

The parent measures the "win" with . Every symbol, plainly:

WHY a sum? Because forced-dead-weight piles up per implementer, and we want the total pain across everyone. WHAT it looks like: stack the wasted buttons from each implementer into one tall column — that height is .

Figure — SOLID — Interface Segregation Principle

Prerequisite map

Method = one named action

Interface = menu of methods

Implement = wire up every method

Client = caller AND implementer

Role interface = methods one client uses

Cohesion = do methods belong together

Forced-dependency count F

Interface Segregation Principle

Equipment checklist

  • I can define a method in one sentence ::: a single named action a piece of code can perform, written verb().
  • I can define an interface ::: a named list of methods a class promises to provide, without saying how.
  • I know what implement forces ::: supplying real working code for EVERY method on the interface, no skipping.
  • I can name the two kinds of client ::: the caller (presses buttons) and the implementer (wires them up).
  • I can explain a role interface ::: a small interface holding only the methods one kind of client uses together.
  • I can state what cohesion measures ::: how strongly the methods on one interface belong together for the same client.
  • I can read ::: total forced/unused method dependencies summed over all implementers.
  • I can compute the printer example ::: forced dependencies removed by ISP.

Connections