Introduction to the Interface Segregation Principle
The Interface Segregation Principle (ISP) is the fourth principle in the SOLID design principles. It states:
"Clients should not be forced to depend on interfaces they do not use."
This means that a class should only implement the methods it actually needs. Large, general-purpose interfaces can become problematic when they force implementing classes to include methods they don't require. Instead, it's better to create smaller, more focused interfaces.
The Problem: A Bloated Printer Interface
Let’s explore this principle using a real-world example: a printer system.
Imagine you’re tasked with designing a system for different types of printers. You decide to create a single interface for all printer-related functions. It might look like this:
public interface Printer {
void printDocument(String document);
void scanDocument(String document);
void faxDocument(String document);
void stapleDocument(String document);
}At first glance, this seems fine. The Printer interface has methods for printing, scanning, faxing, and stapling documents. However, what happens when you need to implement a simple BasicPrinter that only prints and doesn’t support scanning, faxing, or stapling?
Step 1: Implementing BasicPrinter
Let’s try to implement a basic printer that only prints documents.
public class BasicPrinter implements Printer {
@Override
public void printDocument(String document) {
System.out.println("Printing document: " + document);
}
@Override
public void scanDocument(String document) {
// This printer can't scan, so we throw an exception
throw new UnsupportedOperationException("Basic printer can't scan documents.");
}
@Override
public void faxDocument(String document) {
// This printer can't fax, so we throw an exception
throw new UnsupportedOperationException("Basic printer can't fax documents.");
}
@Override
public void stapleDocument(String document) {
// This printer can't staple, so we throw an exception
throw new UnsupportedOperationException("Basic printer can't staple documents.");
}
}As you can see, we’re already running into problems. The BasicPrinter class is forced to implement methods it doesn’t need, such as scanDocument(), faxDocument(), and stapleDocument(). Since it can’t perform these actions, we end up throwing exceptions. This bloats the code and creates unnecessary complexity.
Step 2: Implementing AdvancedPrinter
Now, let’s say we need to implement an AdvancedPrinter that supports all the functionalities (printing, scanning, faxing, and stapling).
public class AdvancedPrinter implements Printer {
@Override
public void printDocument(String document) {
System.out.println("Printing document: " + document);
}
@Override
public void scanDocument(String document) {
System.out.println("Scanning document: " + document);
}
@Override
public void faxDocument(String document) {
System.out.println("Faxing document: " + document);
}
@Override
public void stapleDocument(String document) {
System.out.println("Stapling document: " + document);
}
}The AdvancedPrinter works fine because it supports all the methods in the interface. But notice how both BasicPrinter and AdvancedPrinter had to implement the same interface, even though the BasicPrinter doesn’t use most of the methods.
Why This is a Problem
The problem here is that the Printer interface is too large. It forces classes that don’t need certain methods (like scanDocument() or faxDocument()) to implement them anyway. This leads to unnecessary code, and we’re left with methods that either do nothing or throw exceptions.
In other words, the classes are depending on methods they don’t use, violating the Interface Segregation Principle. The BasicPrinter should not be forced to implement scanning, faxing, or stapling, but because of the large interface, it has no choice.
🤖 Don't fully get this? Learn it with Claude
Stuck on Introduction to the Interface Segregation Principle? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Introduction to the Interface Segregation Principle** (OO & Low-Level Design) and want to truly understand it. Explain Introduction to the Interface Segregation Principle from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Introduction to the Interface Segregation Principle** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Introduction to the Interface Segregation Principle** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Introduction to the Interface Segregation Principle** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.