Interface Segregation Principle (ISP)
No client should be forced to depend on methods it does not use. Prefer many narrow, role-specific interfaces over one fat, general-purpose interface.
ISP = restaurant menus. Don't hand the vegan a 40-page steakhouse menu — give them a focused vegan menu. Each diner (client) gets only the options (methods) they can actually use.
A fat interface creates brittle coupling: if a class is forced to implement 10 methods but only 3 are relevant, it must provide stub implementations that violate the contract or throw exceptions. ISP says: split the interface by the set of clients that use it. A Worker interface with work() and eat() forces robots to implement eat() — split into Workable and Feedable. Each client depends only on the interface it uses.
ISP is the interface-level complement to SRP. Where SRP splits classes by actor, ISP splits interfaces by client. In practice, the violation is detected by searching for empty/throwing implementations of interface methods. The remedy is role interfaces — each interface represents one role a client plays. In dynamically typed languages (Python, JavaScript), ISP manifests as duck typing: a function that only calls .read() should accept anything with .read(), not mandate a full FileIO interface. In REST API design, ISP appears as the argument against returning monolithic response objects — clients should not receive fields they do not need.
ISP tells me to keep interfaces narrow and client-focused. If I'm designing a Document interface with open(), save(), print(), and fax() methods, a DocumentViewer that only reads files is forced to depend on save and fax — methods it cannot meaningfully implement. I split into Readable, Writeable, Printable, and Faxable. ViewOnly clients depend only on Readable. This also makes mocking in tests trivial — mock only the interface you need.
ISP does not mean every interface must have exactly one method. Single-method interfaces (SAM) are common in functional code but ISP is about client need. An interface with five methods that all serve the same client cohesively is fine.