Interface Segregation — Clients shouldn't depend on unused methods
Split fat interfaces so clients only depend on what they use. · No dummy / throw implementations for unused methods.
Watch
Watch, then scroll down for code and practice.
In code
interface Workable {
work(): void;
}
interface Feedable {
eat(): void;
}
class Human implements Workable, Feedable {
work() {}
eat() {}
}
class Robot implements Workable {
work() {}
}📘 Key ideas
The principle
No client should be forced to implement methods it doesn't use. Fat interfaces force implementors to stub out irrelevant methods.
The smell
RobotWorker throws UnsupportedOperationException for eat() and sleep(). That's a sign the Worker interface is too fat.
The fix
Split into Workable, Eatable, Restable. HumanWorker implements all three. RobotWorker implements only Workable.
Benefit
Supervisor only depends on Workable — it can manage both humans and robots without knowing about eating or sleeping.
🧠 Practice — Apply What You Learned
SRP: Fix the Overloaded Logger
You are given a Logger class that does too much: it formats log messages, filters by level…
OCP: Extend Discounts Without Modifying
A PriceCalculator class uses a long if-else chain to apply discounts: if user is Student, …
LSP: The Square–Rectangle Problem
The classic LSP violation: Square extends Rectangle. Since a square's width and height mus…
ISP: Break the Fat Worker Interface
A Worker interface has four methods: work(), eat(), sleep(), requestLeave(). HumanWorker i…
DIP: Decouple the Database Layer
UserService directly instantiates MySQLDatabase inside its constructor: `this.db = new MyS…
Logger / Logging Framework
Design a flexible logging framework that supports multiple log levels, formatters, and out…
Payment Gateway
Design a payment processing system that handles transactions across multiple payment metho…
🚀 Now apply what you learned
Pick a problem above, write your solution, and get AI feedback on your design.
Start Practice →