Zasada segregacji interfejsów – czwarta zasada SOLID.
W teraźniejszości jest wiele metod i zasad programowania, którymi kierują się obecni programiści. W programowaniu obiektowym podstawowym założeniem czystego kodu jest wymyślone przez Martin’a, 5 zasad dobrego programowania tzw. SOLID. Czwartą z pięciu założeń SOLID, jest zasada segregacji interfejsów. Mówi ona o tym, że wiele dedykowanych interfejsów jest lepsze niż jeden ogólny. W tym artykule opisze tą zasadę oraz przedstawię przykład kodu programu przed użyciem tej zasady i po.
Zasada segregacji interfejsów z ang. Interface segregation principle jest jedną z prostszych zasad w SOLID. W sposób łatwy określa, żeby nie tworzyć interfejsów z metodami, których nie używa klasa. Inaczej mówiąc interfejsy powinny być spójne i małe, żeby później klasy nie implementowały metod, których nie potrzebują. Interfejsy powinny być jak najmniejsze i konkretne. Niniejsza zasada skłania do bycia zwięzłym w definiowaniu pojedynczych interfejsów. Tworzone interfejsy powinny zawierać minimalną liczbę deklaracji metod, a same metody powinny być ze sobą ściśle powiązane poprzez obszar swojej funkcjonalności. Zwięźlejsze interfejsy są łatwiejsze w wielokrotnym używaniu i nie przyczyniają się do zwiększenia kodu. W praktyce lepiej będzie zdefiniować większą ilość lżejszych, osobnych interfejsów które są spójne, bo zapewni nam to dużo większa elastyczność, klasa będzie implementowała tylko te interfejsy, które są jej potrzebne, tylko te interfejsy które zawierają po prostu absolutnie niezbędne metody.
Przykład
Poniżej znajduje się część programu odpowiadająca za wysłanie wiadomości.
<?php
interface Message
{
public function prepareMessage();
public function getPhoneNumber();
public function getEmail();
public function send();
}
class SMS implements Message
{
public function prepareMessage()
{
echo 'Przygotowuje wiadomosc<br>';
}
public function getPhoneNumber()
{
echo 'Sprawdzam numer telefonu<br>';
}
public function send()
{
echo 'Wysylam wiadomosc<br>';
}
}
?>
Kod 1. Kod bez zastosowania czwartej zasady SOLID
Jak widzimy klasa SMS implementuje interfejs Message zatem musi też zaimplementować wszystkie cztery metody z tego interfejsu, jednakże metoda getEmail() dla SMS-a nie jest potrzebna. Gdy nie zaimplementujemy tej metody do klasy SMS wyskoczy nam błąd w programie. Można zauważyć, że przez to zmuszamy niepotrzebnie klasę SMS do implementacji wszystkich metod interfejsu. Aby rozwiązać ten problem i odwołując się do czwartej zasady SOLID, rozdzielamy istniejący interfejs i wprowadzamy nowe interfejsy SMSMessage oraz EmailMessage. Dzięki temu otrzymujemy lżejsze interfejsy oraz bardziej elastyczną strukturę kodu.
<?php
interface Message
{
public function prepareMessage();
public function send();
}
interface SMSMessage
{
public function getPhoneNumber();
}
interface EmailMessage
{
public function getEmail();
}
class SMS implements Message, SMSMessage
{
public function prepareMessage()
{
echo 'Przygotowuje wiadomosc<br>';
}
public function getPhoneNumber()
{
echo 'Sprawdzam numer telefonu<br>';
}
public function send()
{
echo 'Wysylam wiadomosc<br>';
}
}
class Email implements Message, EmailMessage
{
public function prepareMessage()
{
echo 'Przygotowuje wiadomosc<br>';
}
public function getEmail()
{
echo 'Sprawdzam adres email<br>';
}
public function send()
{
echo 'Wysylam wiadomosc<br>';
}
}
?>
Kod 2. Kod z zastosowaniem czwartej zasady SOLID
Podsumowanie
Jak widać w programie powyżej wykonaliśmy segregację interfejsów, wydzieliliśmy osobne funkcjonalności do osobnych interfejsów. Teraz klasy implementują tylko te interfejsy, które są im absolutnie potrzebne. Unikamy niepotrzebnego wymuszania implementacji metod, które akurat w danej klasie nie są potrzebne, do SMS-a nie potrzebujemy email-a, a do email-a nie potrzebujemy numeru telefonu. Takie rozwiązanie również wykorzystano w aplikacji Personal Budget. Podsumowując, zasada segregacji interfejsów wymusza budowanie wielu krótkich i zwięzłych interfejsów. Unikamy rozbudowanych gigantów, które dostarczają wielu problemów i niejasności, gdy je wielokrotnie używamy.