Deep Dive
low level designoopdesign principles

Interface Segregation: Don't Make Callers Depend on What They Don't Use

One fat Notifier interface forces every channel to stub methods it can't support and every caller to depend on methods it never calls. Interface Segregation splits it into roles.

·7 min read
Medium

Notifier started with send. Then someone needed batches, so sendBulk went on the interface. Then rich messages, then scheduling. Now every channel implements all four — and SmsChannel fulfills two of them with throw new UnsupportedOperationException(). Worse: the one-line “text me an OTP” service compiles against sendBulk, sendRich, and schedule it will never call.

Below, the members-only continuation makes the split concrete: an interactive splitter that collapses the stub count and the send-only client’s dependency count as you toggle from one fat Notifier to segregated roles, the before/after refactor in code, the rules for where to split, the tradeoffs, and an interview corner with a repository-splitting challenge and quiz.

Members only

Keep reading with Premium

You've reached the members-only part of this deep-dive — the full implementation, the interactive ring simulator, and the step-by-step walkthrough. Unlock it with a membership.