Zasada segregacji interfejsów jest bardzo prosta i nie wymaga zbyt obszernego tłumaczenia.
Klasy nie powinny być zmuszane do zależności od metod, których nie używają.
W myśl tej zasady interfejsy powinny być, skromne, odpowiedzialne za jak najmniejszą funkcjonalność. Użytkownik implementujący taki interfejs nie powinien być zmuszony do implementacji metod, których klienci interfejsu nie używają.
A co z klasami?
Dotyczy to również klas, a mianowicie chodzi o to, aby, nie było zbyt wiele publicznych metod dostarczonych przez klasy, szczególnie wtedy, gdy interakcję z obiektem takiej klasy, nie są ograniczone przez wąski interfejs lub klasę nadrzędną. Duża ilość publicznych metod może wtedy prowadzić do wielu zależności.
Bo może się kiedyś przyda.
Trochę mądrzejsze obiekty, takie co potrafią działać w wielu kontekstach, a może i z kilkoma dodatkowymi metodami, które „mogą się kiedyś przydać”, mogą być przyczyną powstania „grubych interfejsów”. Często może się tak dziać, gdy interfejs jest wydzielany na podstawie implementacji, a tak nie powinno się robić. To interfejs powinien wymuszać implementację, a nie na odwrót.
Implementacja wielu interfejsów przez jedną klasę
Innym podejściem, może być implementacja wielu interfejsów, szczególnie, wtedy gdy, obiekt działa w różnych kontekstach. To w niektórych przypadkach może okazać się zgubną praktyką. Może się okazać, że obiekty takie będą mieć rozmytą odpowiedzialność i realizować zbyt dużo zadań.
To może dziedziczenie?
Kolejne podejście to rozszerzanie funkcjonalności obiektu przez dziedziczenie. Można implementować kolejne interfejsy na kolejnych poziomach dziedziczenia. Takie podejście wydaje się już trochę lepsze, bo odseparowujemy odpowiedzialności do różnych klas i nadal można ukryć obiekt za różnymi interfejsami i cieszyć się jego przystosowaniem do różnych kontekstów.
A może tak jakiś Adapter ?
Czasem dużo lepiej użyć wzorca Adaptera, z rozszerzeniem zachowania, niż wielokrotnie dziedziczyć lub – co gorsza – dodawać implementację do bieżącej klasy. Nowe zachowania dodajemy wtedy jedynie w kontekście danego kontekstu. Implementacja podstawowej klasy obiektu będzie prosta, a jeżeli klient będzie, potrzebował dodatkowych funkcjonalności, to może skorzystać z adaptera, który opakuje podstawowy obiekt w wymagany interfejs i funkcjonalność, tylko tam, gdzie jest to potrzebne.
Jakie plusy ?
Zasada segregacji interfejsów prowadzi do prostych zwartych interfejsów oraz mniejszej ilości zależności między obiektami, poprzez ograniczenie liczby metod możliwych do wywołania przez klientów, dodatkowo zmniejsza ryzyko występowania tak zwanych „God Objects”, lub powstawania niepełnych implementacji.
