Interface Segregation Principle

No client should be forced to depend on methods it does not use.

The violation

One fat interface for everyone who works in the shop:

interface BookshopStaff {
    String sell(Book book, Customer customer);
    void restock(Book book, int copies);
    BigDecimal dailyTakings();
}

class WeekendTemp implements BookshopStaff {
    public String sell(...) { ... }                       // the actual job
    public void restock(...) { /* not allowed to */ }     // forced stub
    public BigDecimal dailyTakings() { throw ...; }       // forced landmine
}

Every implementer stubs or throws the methods that aren’t theirs, every client that only needs selling still sees (and can call!) accounting methods, and a change to restock’s signature recompiles the till code.

The fix

Role-sized interfaces: Bookseller, StockManager, Accountant. ShopManager genuinely does all three and implements all three; WeekendTemp implements exactly the one that’s true.

Benefits

• No forced stubs or landmine methods – implementing an interface means honestly providing all of it.
• Least privilege – till code that takes a Bookseller cannot call dailyTakings() on it.
• Smaller blast radius – changing the stock interface touches stock code, not the till.
• Honest capabilities – what a class implements documents what it can actually do.

Example test

StaffRolesIspTest