Mastering "I" in S.O.L.I.D

“A class should not be forced to implement interfaces it does not use.“

👀 Real Life Example

Let’s imagine we are designing an app for different types of workers:

❌ Bad Example (Violating ISP)

public interface Worker {
    void work();
    void eat();
}

Now we have:

public class HumanWorker implements Worker {
    public void work() {
        System.out.println("Human working...");
    }

    public void eat() {
        System.out.println("Human eating...");
    }
}

public class RobotWorker implements Worker {
    public void work() {
        System.out.println("Robot working...");
    }

    public void eat() {
        // ❌ Robot doesn’t eat — but it’s forced to implement this
        throw new UnsupportedOperationException("Robot can't eat");
    }
}

👉 Here, the RobotWorker is forced to implement eat() even though it doesn’t make sense — violating Interface Segregation Principle.

✅ Good Example (Following ISP)

We break the interface into smaller, more specific ones:

public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

Now we can do:

public class HumanWorker implements Workable, Eatable {
    public void work() {
        System.out.println("Human working...");
    }

    public void eat() {
        System.out.println("Human eating...");
    }
}

public class RobotWorker implements Workable {
    public void work() {
        System.out.println("Robot working...");
    }
}

✅ Each class now implements only what it needs.

⚙️ In Real-World Development

• This principle makes your code modular and flexible.

• It becomes easier to extend and maintain.

• Commonly used in Spring Boot, where services implement specific small interfaces rather than one huge one.

The Interface Segregation Principle (I in SOLID) is mostly used to solve problems related to “fat interfaces” — that is, when interfaces become too large and force classes to implement unnecessary methods.

Let’s break it down clearly 👇

---

⚠️ Main Issue It Solves

“Too many responsibilities or unnecessary methods in one interface.”

In short —
It solves tight coupling and unnecessary implementation problems between interfaces and classes.