What if your software could be as simple and clear as using the right remote for each device?
Why Interface Segregation Principle in LLD? - Purpose & Use Cases
Imagine you have a big remote control that tries to operate every device in your house: TV, air conditioner, lights, and even the coffee machine. You have to scroll through many buttons you never use for each device.
This big remote is confusing and slow. You press wrong buttons often, and it's hard to learn. It's like forcing everyone to carry a huge toolbox when they only need a screwdriver.
The Interface Segregation Principle says: make small, focused remotes for each device. Each remote has only the buttons needed for that device. This keeps things simple, clear, and easy to use.
interface AllInOneDevice {
void play();
void pause();
void setTemperature();
void turnOnLights();
void brewCoffee();
}interface MediaPlayer {
void play();
void pause();
}
interface ClimateControl {
void setTemperature(int temperature);
}
interface Lighting {
void turnOnLights();
}
interface CoffeeMaker {
void brewCoffee();
}It enables building systems that are easier to understand, maintain, and extend without breaking unrelated parts.
Think of smartphone apps: each app has only the features it needs, not a giant app trying to do everything. This keeps apps simple and user-friendly.
Big interfaces confuse and slow down development.
Small, focused interfaces make code cleaner and easier to use.
Interface Segregation Principle helps avoid unnecessary dependencies.
Practice
Interface Segregation Principle in system design?Solution
Step 1: Understand the principle's goal
The Interface Segregation Principle aims to keep interfaces small and focused so clients are not forced to depend on unused methods.Step 2: Match the correct description
Clients should only depend on methods they actually use. correctly states that clients should only depend on methods they use, which aligns with the principle.Final Answer:
Clients should only depend on methods they actually use. -> Option CQuick Check:
Interface Segregation Principle = Clients depend only on used methods [OK]
- Thinking interfaces must be large and cover all features
- Believing all classes must implement every interface method
- Assuming interfaces should be avoided
Solution
Step 1: Analyze interface sizes
interface Printer { void print(); } interface Scanner { void scan(); } splits responsibilities into separate interfaces for printing and scanning, keeping them focused and small.Step 2: Compare with other options
Options A, B, and C combine multiple unrelated methods into one interface, violating the principle.Final Answer:
Separate interfaces for each responsibility -> Option DQuick Check:
Small focused interfaces = interface Printer { void print(); } interface Scanner { void scan(); } [OK]
- Choosing interfaces with many unrelated methods
- Ignoring separation of concerns
- Confusing interface segregation with inheritance
interface Printer { void print(); }
interface Scanner { void scan(); }
class MultiFunctionDevice implements Printer, Scanner {
public void print() { System.out.println("Printing document"); }
public void scan() { System.out.println("Scanning document"); }
}
MultiFunctionDevice device = new MultiFunctionDevice();
device.print();
device.scan();Solution
Step 1: Understand class implementation
The class implements both Printer and Scanner interfaces and provides both methods.Step 2: Trace method calls
Calling device.print() prints "Printing document" and device.scan() prints "Scanning document".Final Answer:
Printing document\nScanning document -> Option AQuick Check:
Both methods print messages = Printing document\nScanning document [OK]
- Assuming only one method runs
- Expecting compilation error due to multiple interfaces
- Confusing method outputs
interface Worker {
void work();
void eat();
}
class Robot implements Worker {
public void work() { System.out.println("Robot working"); }
public void eat() { throw new UnsupportedOperationException(); }
}Solution
Step 1: Analyze interface methods
The Worker interface combines work and eat methods, but Robot cannot eat.Step 2: Identify violation
Robot is forced to implement eat() which it does not support, violating Interface Segregation Principle.Final Answer:
Worker interface is too broad, forcing Robot to implement unused methods. -> Option AQuick Check:
Broad interface forcing unused methods = Worker interface is too broad, forcing Robot to implement unused methods. [OK]
- Thinking Robot must implement eat() properly
- Believing no problem exists
- Suggesting Robot should avoid interface
Solution
Step 1: Evaluate interface segregation
interface CardPayment { void payWithCard(); } interface CashPayment { void payWithCash(); } interface CryptoPayment { void payWithCrypto(); } splits payment methods into separate interfaces, allowing clients to implement only what they need.Step 2: Compare other options
Options A, B, and D force clients to implement methods they may not use, violating the principle.Final Answer:
Separate interfaces for each payment method -> Option BQuick Check:
Separate interfaces = interface CardPayment { void payWithCard(); } interface CashPayment { void payWithCash(); } interface CryptoPayment { void payWithCrypto(); } [OK]
- Combining all payment methods in one interface
- Forcing classes to implement unused methods
- Ignoring interface segregation benefits
Ready to prove it?
Pass the test and this pattern moves unknown
