Daj Się Poznać Programowanie SOLID

SOLID #5 ZASADA ODWRACANIA ZALEŻNOŚCI

Przyszedł czas na ostatni artykuł dotyczący mnemoniku SOLID a wraz z nim literkę D czyli zasadę odwracania zależności (ang. Dependency Inversion Principle). Jeżeli jakimś cudem jeszcze nie wiesz co kryje się pod skrótem SOLID zapraszam Cię do tego artykułu.

CO TO JEST ZASADA ODWRACANIA ZALEŻNOŚCI

Zasada ta składa się z dwóch następujących części:

  1. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.
  2. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.

Patrząc na tą zasadę pod innym kontem można powiedzieć, że nasze moduły nie powinny zależeć od konkretnych implementacji, ale od abstrakcji (interfejsów). Jak widać zasada ta ściśle współpracuje z zasadą segregacji interfejsów (o której możesz przeczytać tutaj).

ALE O CO CHODZI Z TYM ODWRÓCENIEM?

Projektowanie aplikacji jest bardzo często porównywalne do budownictwa, gdzie aby powstał dom najpierw jest konieczność wylania fundamentów, potem kładziemy podmurówkę, która zależy od fundamentów. Następnie stawiamy ściany, które zależą od dwóch poprzednich elementów itd. Jednak zasada ta nie sprawdza się jeżeli chodzi o projektowanie i inżynierię. Nie ma jednego kierunku i nic nie zabrania nam rozpoczęcia pracy nad „budynkiem” ( w naszym przypadku projektem) od komina. Części produkuje się osobno, dopiero na końcu składa się je w jedną całość. Takimi częściami programu są np. klasy, obiekty itp.

Odwrócenie zależności to nic innego jak budowanie aplikacji od góry. To nie dobry kod jest celem aplikacji. Program musi być użyteczny, musi spełniać logikę biznesową. Pierwszym krokiem jest zastanowienie się nad tym jakie wymagania musi spełniać nasza aplikacja. Potem programujemy logikę, a dopiero na końcu tworzymy finalny produkt, który dostosowuje się do naszej logiki.

Projektowanie zaczynamy od interfejsów, wspólnie opracowujemy szkielet aplikacji. Gdy zaprojektowany zostanie wstępny wygląd aplikacji (od strony logiki biznesowej, a nie graficznej), różne zespoły programistów mogą niezależnie pracować nad różnymi fragmentami projektu komunikując się tylko i wyłącznie przez interfejsy.  W ten sposób żadne moduły aplikacji nie zależą od siebie tylko od wspólnych abstrakcji.

CO NAM DAJE DEPENDENCY INVERSION

  1. Testowanie aplikacji jest łatwiejsze, ponieważ wiemy co dany moduł/klasa mają robić (mówi to interfejs) i w łatwy sposób możemy napisać testy jednostkowe.
  2. Równoległa praca nad elementami systemu jest możliwa. Dzięki komunikacji za pomocą interfejsów programiści nie wchodzą sobie w drogę.
  3. Zmiany w systemie są łatwe. Jeżeli chcemy dodać jakąś nową funkcjonalność ten sam interfejs implementujemy w nowy sposób- reszta systemu pozostaje bez zmian.

 

UWAGA

Dependency Inversion Principle to nie to samo co DI (Dependency Injection czyli wstrzykiwanie zależności). Di jest sposobem spełniania zasady DIP.

 

PODSUMOWANIE

Zasada odwracania zależności to finał całego mnemonika SOLID. Zachęca ona do uzależniania się od abstrakcji, a nie od konkretnych implementacji rozwiązań. Innymi słowy zasada ta mówi abyśmy używali interfejsów i klas abstrakcyjnych wszędzie tam, gdzie wydaje się że może to być użyteczne w przyszłości.

Dodaj komentarz