SOLID – część 5. Zasada odwrócenia zależności

SOLID – mnemonik, który mówi jak pisać poprawnie programy w językach obiektowych. Podążanie za tymi zasadami znacznie poprawia czytelność i możliwość utrzymywania kodu. Część piąta: Zasada odwrócenia zależności.

Dochodzimy do ostatniej zasady. Zasada odwrócenia zależności czyli Dependency inversion principle.
Spójrzmy co mówi DIP:

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji.

Aby lepiej to zrozumieć o co chodzi spójrzmy na nasz aktualny kod:

Aktualnie tworząc klasę czołgu nie mamy wpływu no to, jaki ten czołg powstanie – z jakich elementów się będzie składać. To z jakich elementów ten czołg się będzie składać zapisane jest w konstruktorze czołgu. Czołg jest tutaj modułem wysokopoziomowym. Lufa, karabin, pancerz czy napęd są modułami niskopoziomowymi.

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych

W tym momencie nasz czołg zależy od modułów niskopoziomowych. Jak temu zaradzić?

zależności między nimi powinny wynikać z abstrakcji

Wpierw odpowiedzmy sobie na kilka pytań.
Czym jest abstrakcja w naszym programie? Abstrakcją są interfejsy lub klasy bazowe (np. lufa).
Jak wprowadzić zależności pomiędzy modułami wysokopoziomowymi a niskopoziomowymi? Używając odwróconego sterowania (Inversion of Control – IoC).
Czym jest IoC? Jest to wzorzec, który po zaimplementowaniu spowoduje, że nasz kod będzie działać zgodnie z zasadą odwróconego sterowania.
Jak działa IoC? W naszym przykładzie będzie używać typu IoC Creation inversion. Zasada działa jest prosta: moduły wysokopoziomowe „same sobie wybierają” jakich modułów niskopoziomowych chcą używać. Aktualnie czołg ma na stałe wpisane jaki ma mieć napęd czy lufę.

Wprowadźmy do naszego programu IoC. A dokładniej użyjemy najpopularniejszej implementacji wzorca IoC czyli wstrzykiwanie zależności (Dependency Injection).

W tym momencie czołg sam sobie może wybrać jakich chce używać elementów. To my możemy kontrolować czołgiem z wysokiego poziomu, bez potrzeby wgłębiania się w implementację niskich poziomów.
W ten sposób nasz program spełnia teraz zasadę DIP. Używamy w tym celu DI, a dokładniej Constructor injection.

DIP a DI to nie to samo. DIP to Dependency inversion principle (zasada odwróconego sterowania), natomiast DI to Dependency Injection (wstrzykiwanie zależności). DI jest sposobem spełniania zasad odwróconego sterowania.

W naszym programie używamy jeszcze jednego wstrzykiwania zależności.

LadujPocisk jest przykładem DI Method injection. Z wysokiego poziomu mamy możliwość ustawić jaki pocisk chcemy załadować.

Jakie korzyści otrzymujemy dzięki używaniu DIP?

  • System teraz jest bardziej elastyczny.
  • Mamy większą pewność, że zmiana komponentu nie przyniesie niepożądanych skutków (wszystko działa na abstrakcjach).
  • Kod jest bardziej przenaszalny na inne projekty.

SOLID – Zasada odwrócenia zależności. Linki.

Podstawy DIP
Wytłumaczenie IoC
Świetnie opisany DIP, IoC oraz DI
Seria artykułów o IoC oraz DI

Powered by: Wordpress