Interface Segregation Principle czyli interfejs powinien być jak modelka–przeraźliwie chudy

Jestem fanem interfejsów jak to wcześniej już pisałem, zatem dzisiaj będzie temat łatwy i przyjemny o interfejsach właśnie. W sam raz na ciężki po długo weekendowy poniedziałek.

Interface Segregation Principle mówi, że klient nie powinien być zmuszany do implementowania interfejsów, których nie używa. Z tego wynika, że interfejs powinien być minimalistyczny lub po prostu możliwie chudy. Idealnie by było, gdyby miał jedną metodę Uśmiech a poważnie, można by tutaj parafrazować Single Responsibility Principle i powiedzieć, że interfejs powinien definiować jedną czynność (logiczną czynność – nie metodę/funkcję).

Dlaczego to jest ważne? Dlaczego wielkie grube interfejsy są nie fajne? Dlatego, że ktoś kto będzie musiał zaimplementować wielki barokowy interfejs najprawdopodobniej większość metod pozostawi pustych (lub z NotImplementedException) a zaimplementuje te, które są dla niego niezbędne. To znowu może prowadzić do dziwnych wyjątków i dziwnego działania aplikacji, jeśli taki “niedoimplementowany” obiekt zostanie ponownie użyty w innym miejscu. Wszak przy dużych systemach nikt nie czyta całego kodu każdego obiektu tylko go używa mając nadzieję, że jego nazwa i metody rzeczywiście robią to na co wskazują. Zatem nie wprowadzajmy siebie i innych w błąd i nie utrudniajmy sobie życia, twórzmy małe chude interfejsy, które reprezentują jedną spójną i logiczną czynność.