SOLID Principles
Interface Segregation Principle
Clients should not be forced to depend on interfaces they do not use. Many specific interfaces are better than one general-purpose interface.
10 min readEssential
1What is ISP?
Real-World Analogy
Restaurant Menu
A vegetarian should not be handed a 50-page menu with mostly meat dishes. Better to have separate menus: Vegetarian Menu, Non-Veg Menu, Drinks Menu. Each customer gets only what is relevant to them.
Remote Control
A simple TV remote should not have buttons for DVD, gaming, and smart home. Those are for universal remotes. Each device should have an interface with only the buttons it needs.
Interface Segregation Principle (ISP): No client should be forced to depend on methods it does not use. Split large interfaces into smaller, specific ones so that clients only know about methods relevant to them.
Fat Interface vs Segregated Interfaces
❌ Fat Interface
IWorker
work()
eat()
sleep()
eat()
sleep()
Human
Robot
Robot forced to implement eat(), sleep()
✅ Segregated Interfaces
IWorkable
work()
IFeedable
eat()
ISleepable
sleep()
Human: all 3
Robot: work only
2ISP Violation Example
Fat Interface Problem
// ❌ ISP VIOLATION: Fat interface forces unwanted methods
interface IMultiFunctionDevice {
void print(Document doc);
void scan(Document doc);
void fax(Document doc);
void photocopy(Document doc);
}
// Old printer that only prints - forced to implement everything
class OldPrinter implements IMultiFunctionDevice {
@Override
public void print(Document doc) {
// Can print
System.out.println("Printing: " + doc.getName());
}
@Override
public void scan(Document doc) {
// Cannot scan - what to do?
throw new UnsupportedOperationException("Cannot scan!");
}
@Override
public void fax(Document doc) {
// Cannot fax - forced to implement anyway
throw new UnsupportedOperationException("Cannot fax!");
}
@Override
public void photocopy(Document doc) {
// Cannot photocopy
throw new UnsupportedOperationException("Cannot photocopy!");
}
}
// Client code might call any method - runtime errors!
public void processDocument(IMultiFunctionDevice device, Document doc) {
device.print(doc);
device.scan(doc); // Crash if OldPrinter!
}3ISP-Compliant Solution
Split the fat interface into smaller, role-specific interfaces:
Segregated Interfaces
// ✅ ISP COMPLIANT: Segregated interfaces
interface IPrinter {
void print(Document doc);
}
interface IScanner {
void scan(Document doc);
}
interface IFax {
void fax(Document doc);
}
// Old printer implements only what it can do
class OldPrinter implements IPrinter {
@Override
public void print(Document doc) {
System.out.println("Printing: " + doc.getName());
}
// No need to implement scan/fax!
}
// Modern device implements multiple interfaces
class MultiFunctionPrinter implements IPrinter, IScanner, IFax {
@Override
public void print(Document doc) {
System.out.println("Printing: " + doc.getName());
}
@Override
public void scan(Document doc) {
System.out.println("Scanning: " + doc.getName());
}
@Override
public void fax(Document doc) {
System.out.println("Faxing: " + doc.getName());
}
}
// Clients depend only on what they need
class PrintService {
private IPrinter printer; // Only needs print capability
public PrintService(IPrinter printer) {
this.printer = printer;
}
public void printDocument(Document doc) {
printer.print(doc); // Safe - guaranteed to work
}
}
// Usage
public static void main(String[] args) {
// Both work as printers
IPrinter oldPrinter = new OldPrinter();
IPrinter modernPrinter = new MultiFunctionPrinter();
PrintService service = new PrintService(oldPrinter);
service.printDocument(new Document("report.pdf"));
// Scanner service only accepts IScanner
ScanService scanService = new ScanService(new MultiFunctionPrinter());
// scanService = new ScanService(oldPrinter); // Compile error! Good!
}4Benefits of ISP
✅ No Forced Dependencies
Classes only depend on methods they actually use. No dummy implementations needed.
✅ Better Type Safety
Compiler catches incompatible types. No runtime UnsupportedOperationException.
✅ Easier Maintenance
Changes to one interface don't affect unrelated classes.
✅ Clearer Design
Small interfaces are easier to understand and implement.
5Interview Questions
What is the Interface Segregation Principle?
ISP states that clients should not be forced to depend on interfaces they don't use. Instead of one large interface, create smaller specific interfaces. Each client should only see methods relevant to it. This prevents 'fat' interfaces that force implementers to provide dummy implementations.
How do you identify ISP violations?
Signs: 1) Interfaces with many methods that not all implementers need, 2) Classes throwing NotImplementedException or UnsupportedOperationException, 3) Empty method implementations, 4) Classes implementing interfaces but only using few methods. Fix: Split into role-specific interfaces.
How is ISP related to SRP?
They are related but focus differently. SRP: A class should have one reason to change (single responsibility). ISP: A client should not depend on methods it doesn't use (interface granularity). Both promote smaller, focused units. ISP often helps achieve SRP by providing focused interfaces.
6Key Takeaways
1ISP: No client should depend on methods it does not use.
2Split fat interfaces into smaller, role-specific interfaces.
3Each interface should have a cohesive set of methods.
4Signs of violation: NotImplementedException, empty overrides.
5Benefits: Type safety, easier maintenance, clearer design.
6Related to SRP - both promote smaller, focused units.