Duży plus za omawianie zasad SOLID, ale przykłady trochę zbyt przesadzone.
Analizując przykłady, można by wysnuć wniosek, że skoro interfejsy mają być małe, to najlepiej niech zawsze mają tylko jedną metodę. Hmm, skoro to takie proste i mechaniczne, to czemu na internecie jest tak dużo artykułów o ISP? Fakt, czasem tak się da (np. Runnable) i możemy otwierać szampana, bo piszemy SOLIDny kod bez większego wysiłku. Niestety w większości przypadków nie ma tak łatwo i tego typu interfejsy będą strasznie na siłę. Tak jak IWork i IEat. Wybacz :P
Brakło mi podkreślenia, że w tym wszystkich chodzi o dobre zaprojektowanie abstrakcji i jest to naprawdę trudne. Jeśli źle ją zaprojektujesz, to potem na siłę rozbijasz interfejsy na mniejsze, żeby spełnić jakąś tam zasadę. Kiedy jednocześnie inna zasada mówi, że powinieneś maksymalizować spójność (cohesion) ¯\_(ツ)_/¯
Correct abstraction is the key to Interface Segregation Principle
ISP pozwoli Ci określić czy kod jest czysty, czy nie, ale nie za bardzo mówi jak tę mityczną czystość osiągnąć. Tutaj masz świetny artykuł, który porusza właśnie ten aspekt zasady ISP:
This principle comes naturally when you start decomposing your problem space with identifying major roles that take part in your domain. And it’s never a mechanical action. No principle can automatically lead you to the correct object model.
So ISP is a poor guidance when designing software, but an excellent indicator of whether it’s healthy or not. Don’t think about ISP when designing your software. Think about whether your abstractions are reusable and composable, and whether your objects are encapsulated and cohesive.