# Interface Segregation Principle (ISP) in Java

**SOLID Design Principle**

> **"Clients should not be forced to depend on interfaces they do not use."**

The **Interface Segregation Principle (ISP)** is one of the five **SOLID principles** that helps developers design **flexible, maintainable, and scalable software systems**.

This principle focuses on **designing small, specific interfaces** instead of **large, general-purpose ones**.

* * *

# Why Interface Segregation Principle Matters

In real-world applications, not every class needs every method.

When we create **large interfaces**, classes are often forced to implement methods they don't need.

This leads to:

Unnecessary code  
Runtime exceptions  
Hard-to-maintain systems  
Poor scalability

ISP solves this by encouraging:

Smaller interfaces  
Focused responsibilities  
Better modular design

* * *

# 🚨 Problem Scenario — Without ISP (Bad Design)

Let's start with a common mistake.

Suppose we create a **Worker interface**.

```java
interface Worker {
    void work();
    void eat();
}
```

Now we create a Human worker.

```java
class HumanWorker implements Worker {

    @Override
    public void work() {
        System.out.println("Human is working");
    }

    @Override
    public void eat() {
        System.out.println("Human is eating");
    }
}
```

So far, everything looks fine.

* * *

## 🤖 Now Add Robot Worker

Robots don't eat.

But because of the large interface, they are forced to implement `eat()`.

```java
class RobotWorker implements Worker {

    @Override
    public void work() {
        System.out.println("Robot is working");
    }

    @Override
    public void eat() {
        // Robots don't eat
        throw new UnsupportedOperationException(
            "Robot does not eat"
        );
    }
}
```

* * *

# ❗ What's Wrong Here?

This design causes:

### 🔴 Forced Implementation

Robot must implement `eat()` even though it doesn't need it.

### 🔴 Runtime Risk

Throwing exceptions like:

```java
UnsupportedOperationException
```

creates unstable systems.

### 🔴 Maintenance Problems

If more worker types are added, the interface becomes messy.

* * *

# Solution — Apply Interface Segregation Principle

Instead of one large interface,  
we split it into **smaller, specific interfaces**.

* * *

# Step 1 — Create Small Interfaces

```plaintext
interface Workable {
    void work();
}

interface Eatable {
    void eat();
}
```

Now each interface represents **one responsibility**.

* * *

# Step 2 — Implement Only What Is Needed

## 👤 Human Worker

Human works and eats.

```java
class HumanWorker implements Workable, Eatable {

    @Override
    public void work() {
        System.out.println("Human is working");
    }

    @Override
    public void eat() {
        System.out.println("Human is eating");
    }
}
```

* * *

## 🤖 Robot Worker

Robot only works.

```java
class RobotWorker implements Workable {

    @Override
    public void work() {
        System.out.println("Robot is working");
    }
}
```

Now:

✔ Robot doesn't implement unused methods  
  
✔ No exceptions  
  
✔ Clean design

* * *

# Step 3 — Test the Program

```java
public class ISPExample {

    public static void main(String[] args) {

        Workable human = new HumanWorker();
        human.work();

        Workable robot = new RobotWorker();
        robot.work();
    }
}
```

* * *

# Code Flow Explanation

Let's understand the execution flow.

### Step-by-step flow:

1️⃣ `HumanWorker` implements:

*   `Workable`
    
*   `Eatable`
    

So it can:

*   Work
    
*   Eat
    

* * *

2️⃣ `RobotWorker` implements:

*   `Workable` only
    

So it can:

*   Work
    
*   (No eat method exists)
    

* * *

3️⃣ In `main()`:

```java
Workable human = new HumanWorker();
human.work();
```

Only required behavior is used.

* * *

# Real-World Example — Printer System

This is one of the **most popular ISP examples**.

## ❌ Bad Design

```java
interface Machine {
    void print();
    void scan();
    void fax();
}
```

Problem:

Not all machines support all features.

Example:

*   Basic Printer → print only
    
*   Scanner → scan only  
    

But both must implement all methods.

Bad design.

* * *

# ✅ ISP-Based Design

Split into smaller interfaces.

```java
interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

interface Fax {
    void fax();
}
```

* * *

## 🖨️ Multi-Function Printer

Supports all features.

```java
class MultiFunctionPrinter 
        implements Printer, Scanner, Fax {

    public void print() {
        System.out.println("Printing...");
    }

    public void scan() {
        System.out.println("Scanning...");
    }

    public void fax() {
        System.out.println("Faxing...");
    }
}
```

* * *

## 🖨️ Simple Printer

Supports only printing.

```java
class SimplePrinter implements Printer {

    public void print() {
        System.out.println("Simple printing...");
    }
}
```

Now every class implements only what it needs.

Perfect ISP usage.

* * *

# Benefits of Interface Segregation Principle

Using ISP leads to:

✅ Cleaner interfaces  
✅ Better code readability  
✅ Flexible system architecture  
✅ Easier testing  
✅ Reduced coupling  
✅ Improved scalability

* * *

# Signs That ISP Is Being Violated

Look for:

🚩 Interfaces with too many methods  
🚩 Classes implementing unused methods  
🚩 Frequent use of:

```java
UnsupportedOperationException
```

🚩 Difficult-to-maintain interfaces

* * *

# 🧠 ISP in Real Java Frameworks

Many Java APIs follow ISP.

Example:

Java Collections Framework:

```java
List
Set
Queue
Map
```

Instead of one huge interface.

Each interface serves **specific behavior**.

* * *

# Summary

The **Interface Segregation Principle** helps developers create:

✔ Modular systems  
✔ Clean interfaces  
✔ Flexible architecture  
✔ Maintainable applications

Instead of:

❌ Large bloated interfaces  
❌ Forced method implementations  
❌ Runtime failures

* * *

# Final Thought

> **"Many small interfaces are better than one large interface."**

Following ISP leads to **cleaner Java code**, **better design**, and **future-proof systems**.

* * *