Interface Segregation

Clients should not be forced to depend on interfaces or methods they do not use — prefer many small, focused interfaces over one large general-purpose one.

The Problem

A "fat" interface with many unrelated methods forces every implementing class to provide (or stub out) methods it doesn't need, leading to empty or throwing implementations and tight coupling between unrelated clients.

How It Works

›Split large interfaces into smaller, role-specific ones (e.g., Printable, Scannable instead of one Machine interface)
›Classes implement only the interfaces relevant to their behavior
›Clients depend only on the methods they actually call
›Reduces ripple effects — changes to an unused method no longer force changes in unrelated classes

When to Use

✓An interface has methods that only some implementers need

✓Implementing classes throw "not supported" for some interface methods

✓Designing plugin/capability systems (e.g., a printer that can print but not scan)

Real-World Examples

🍎

iOS

Separate protocols like UITableViewDataSource and UITableViewDelegate instead of one giant protocol

🤖

Android

Separate listener interfaces like OnClickListener and OnLongClickListener

🌐

Web

Splitting a generic Repository interface into separate Readable and Writable interfaces

Code Examples

Swift

// ❌ Fat interface forces SimplePrinter to implement scan()/fax() too
// protocol Machine { func print(); func scan(); func fax() }

// ✅ Segregated interfaces — implement only what you support
protocol Printer {
    func print(_ document: String)
}

protocol Scanner {
    func scan() -> String
}

struct SimplePrinter: Printer {
    func print(_ document: String) {
        print("Printing: \(document)")
    }
}

struct AllInOnePrinter: Printer, Scanner {
    func print(_ document: String) { print("Printing: \(document)") }
    func scan() -> String { "Scanned document" }
}