4.
I - Interface Segregation Principle (ISP)
What is the Interface Segregation Principle (ISP)?
Code Example: Violating ISP
Problems with the Above Code
Code Example: Follows ISP
Key Benefits of the Refactored Code
Summary
Resources
Video → 1. SOLID Principles with Easy Examples (Hindi) | OOPs SOLI
D Principles - Low Level Design
What is the Interface Segregation Principle (ISP)?
Interface Segregation Principle (ISP) states that “clients should not be forced to depend on
interfaces they don't use. Instead of having one large interface with many methods, it's
better to have multiple smaller, focused interfaces”.
That means, Interfaces should be such that the client should NOT implement unnecessary functions they do not
need.
Code Example: Violating ISP
1 // BAD: This class violates ISP
2 // This is a fat interface
3 // One large interface forcing all implementers to define unused
methods
4 public interface RestaurantEmployee {
5
6 void prepareFood();
7
8 void decideMenu();
9
10 void serveFoodAndDrinks();
11
12 void takeOrder();
13
14 void cleanTheKitchen();
15 }
16
17
18 // BAD: This class violates ISP(clients shouldn't depend on unused
interfaces)
19 // Bloated class with empty or error-throwing methods
20 // This Waiter is forced to implement methods it doesn't need
21 public class Waiter implements RestaurantEmployee {
22 @Override
23 public void takeOrder() {
24 [Link]("Taking order...");
25 }
26
27 @Override
28 public void serveFoodAndDrinks() {
29 [Link]("Serving food and drinks...");
30 }
31
32 @Override
33 public void cleanTheKitchen() {
34 // Forced to implement but doesn't make sense for a waiter
35 throw new AssertionError("Detail Message: Waiter cannot clean
the kitchen!");
36 }
37
38 @Override
39 public void prepareFood() {
40 // Forced to implement but doesn't make sense for a waiter
41 throw new AssertionError("Detail Message: Waiter cannot
prepare food!");
42 }
43
44 @Override
45 public void decideMenu() {
46 // Forced to implement but doesn't make sense for a waiter
47 throw new AssertionError("Detail Message: Waiter cannot decide
the menu!");
48 }
49
50 }
51
52
53 // Usage example - showing the problem
54 public class ViolationDemo {
55 public static void main(String[] args) {
56 Waiter waiter = new Waiter();
57 // Works fine
58 [Link]();
59 [Link]();
60
61 // These will throw exceptions
62 [Link](); // forced implementation
63 [Link](); // forced implementation
64 [Link](); // forced implementation
65 }
66 }
Problems with the Above Code
Classes are forced to implement methods they don't support.
Results in AssertionError being thrown.
Code becomes bloated with empty or error-throwing methods.
Violates the principle that clients shouldn't depend on unused interfaces.
Code Example: Follows ISP
1 // GOOD: This follows ISP - Multiple focused interfaces following ISP
2 public interface ChefTasks {
3 void prepareFood();
4
5 void decideMenu();
6 }
7
8 // GOOD: This follows ISP - Multiple focused interfaces following ISP
9 public interface WaiterTasks {
10 void serveFoodAndDrinks();
11
12 void takeOrder();
13 }
14
15 // GOOD: This follows ISP - Multiple focused interfaces following ISP
16 public interface MaintenanceTasks {
17 void cleanTheKitchen();
18
19 void reStockGroceries();
20 }
21
22 // GOOD: This class follows ISP
23 // Now classes only implement what they actually need - Clean
implementations
24 public class Chef implements ChefTasks {
25
26 @Override
27 public void prepareFood() {
28 [Link]("Preparing food...");
29 }
30
31 @Override
32 public void decideMenu() {
33 [Link]("Deciding menu...");
34 }
35 }
36
37 // GOOD: This class follows ISP
38 // Now classes only implement what they actually need - Clean
implementations
39 public class Waiter implements WaiterTasks {
40 @Override
41 public void serveFoodAndDrinks() {
42 [Link]("Serving food and drinks...");
43 }
44
45 @Override
46 public void takeOrder() {
47 [Link]("Taking order...");
48 }
49 }
50
51 // Usage example - Following ISP
52 public class SolutionDemo {
53 public static void main(String[] args) {
54 // Create the objects
55 // Now classes only implement what they actually support
56 Chef chef = new Chef();
57 Waiter waiter = new Waiter();
58
59 // Use the objects
60 // These work perfectly - no forced implementations
61 [Link]();
62 [Link]();
63 // These work perfectly - no forced implementations
64 [Link]();
65 [Link]();
66 }
67 }
Key Benefits of the Refactored Code
Prevents bloated classes by having each class implement interfaces that it uses.
No forced dependencies on irrelevant functionality.
Cleaner, more maintainable design/code.
Different Restaurant Employee entities can implement multiple interfaces only when they support those features.
Summary
The Interface Segregation Principle (ISP) helps maintain focused classes by ensuring they only implement the
methods they need. To identify potential violations of the ISP, look for indicators such as low cohesion, large or
“fat” interfaces, empty methods, and challenging testing scenarios. By recognizing these signs early, you can
refactor your code to uphold a modular and flexible design.