ISP LSPZasada „Interface Segregation” stwierdza, że klient nie powinien być zmuszony do implementacji interfejsów, których nie używa. Celem tej zasady jest utrzymanie jednej odpowiedzialności wraz ze wzrostem jednego interfejsu. System nie powinien posiadać grubych interfejsów, a jeśli już takie istnieją to powinny być wydzielone na mniejsze grupy, które mają spójną funkcjonalność.
Pozwala to podklasom na stworzenie implementacji tylko grupy zachowania zamiast implementacji monolitycznej kontraktu, która będzie dziurawa i będzie zawierać wyjątki „NotImplementedException” informujące o braku implementacji danej metody.
Co będzie łamać zasadę „Liskov Substitution” gdyż obiekty pochodne nie będą reprezentowały zachowania obiektu bazowego.
Do demonstracji obu zasad „Interface Segregation” i ”Liskov Substitution” zaprezentuję modele katalogu produktów. Obecnie katalog produktów jest stworzony na bazie produktów filmowych, które są zapisane na dyskach DVD i Blue-Ray.
Obie klasy „DVD” i „Blue-Ray” implementują interfejs „IProduct”. IProdukt zawiera właściwości takie jak: certyfikacja, cena, długość trwania i waga w kilogramach.
Na razie nie ma żadnych problemów z taką strukturą. Jednak co się stanie, gdy zaprezentuję nowy produkt, który nie jest filmem tylko np. koszulką.
Teraz powstaje problem w klasie „T-Shirt” .
Interfejs „IProduct” zawiera właściwości określające czas trwania filmu i jego certyfikacje.
Te właściwości jednak nie mają sensu dla modelu reprezentującego element garderoby.
Rozwiązanie tego problemu zgodnie z zasadą „Interface Segregation” polega na wydzieleniu interfejsu „IProduct” z niepotrzebnych właściwości, które nie określają ogólnych zachowań produktu.
Właściwości takie jak czas trwania filmu i certyfikacja zostały więc wydzielone do innego interfejsu „IMovie” .
Teraz zgodnie z zasadą „Liskov Substitution” wszystkie klasy mają takie same zachowania jakie są opisane w ich klasach bazowych, w tym przypadku interfejsach.
Oto esencja zasady „Interface Segregation”.
Patrząc na ten diagram możesz też się zastanowić nad sensem właściwości określającej wagę produktu. Czy jest ona potrzebna w każdy produkcie? Może trzeba wydzielić tą właściwość na kolejny interfejs.
Brak zastosowania tej zasady widać w framework ASP.NET przy interfejsie „IMembershipProvider”, który zawiera wiele metod, które niekoniecznie muszą być zaimplementowane do logowania użytkownika.
Dlatego warto pamiętać o tej zasadzie. Podział interfejsów na mniejsze nie wymaga napisana kodu od nowa, a tylko zmiany jego definicji.
Ostatecznie będziemy mieć świadomość, że inni użytkownicy tego kodu nie będą oszukiwać w implementacjach interfejsu, gdy jest niezgodny z modelem, który chcą zobrazować.
Trzymając się zasady „Interface Segregation” mamy pewność, że inni programiści nie będą zmuszeni łamać zasady „Liskov Substitution”.
