ISP Structure: Fat Interface vs Segregated Interfaces
The key structural pattern in ISP is decomposing one large interface into multiple small interfaces based on client needs and behavioral cohesion.
Anti-Pattern: Fat Interface
+ eat(): void
+ sleep(): void
+ getSalary(): Money
+ attendMeeting(): void
Problem: A Robot worker cannot eat or sleep. A Contractor may not attend meetings or receive salary the same way. Each implementer is forced to handle irrelevant methods.
ISP Solution: Segregated Interfaces
Now HumanEmployee implements Workable, Feedable, Payable, and MeetingAttendee. Robot implements only Workable. Contractor implements Workable and Payable but not MeetingAttendee if contractors work remotely without meetings.
Key Relationships
Interface Composition: Classes implement multiple small interfaces instead of one large interface. This is expressed as multiple realization arrows (dashed lines with hollow triangles) from the class to each interface.
Client Dependencies: Clients depend only on the interface they need. A WorkScheduler depends on Workable, while PayrollSystem depends on Payable. Neither client is coupled to methods it does not call.