SOLID – Zasada odwracania zależności

Posted on by 0 comment

Finalnym wyliczeniem skromnej listy zasad SOLID jest Zasada odwracania zależności (Dependency inversion principle). Jeśli jeszcze nie wiesz, co kryje pod sobą akronim SOLID, zapraszam do odpowiedniego artykułu.

SOLID - Zasada odwracania zależności

SOLID – Zasada odwracania zależności

Zasada odwracania zależności

Zasada odwracania zależności współpracuje ściśle z Zasadą segregacji interfejsów (klienci nie powinni zależeć od interfejsów, których nie używają). W tym przypadku zejdziemy troszkę niżej, bo do poziomu konkretnych struktur, np. klas.

Zasada odwracania zależności mówi, że nasze moduły (np. klasy) nie powinny zależeć od konkretnych implementacji, ale od abstrakcji.

Co to znaczy?

Nic innego jak oparcie implementacji naszych rozwiązań na abstrakcyjnych bytach (interfejsach, klasach abstrakcyjnych) i efektywne ich wykorzystywanie.

Przykład

Przechodząc przez kolejne warstwy SOLID, wiele razy posługiwałem się bardzo wymownymi przykładami. Nie inaczej tym razem, zainsynuujmy kolejną barwną sytuację 🙂

Załóżmy, że pracujemy w nowoczesnej fabryce samochodów. Otrzymujemy za zadanie oprogramowanie mechanizmu podgrzewania foteli typu FotelQ7, który będzie uruchamiany po naciśnięciu odpowiedniego przycisku.

Zaczynamy od oprogramowania podgrzewania fotelu:

Posiadamy już wymaganą funkcjonalność, teraz udostępnijmy ją użytkownikowi samochodu:

Oczywiście to rozwiązanie, jak i też wiele innych będzie działać, ale skupiając się na opisywanej zasadzie, spróbujmy je pod tym kątem zoptymalizować.

Główną bolączką, która wynika z tego przykładu, jest to, że przycisk podgrzewania jest w stanie obsługiwać, tylko jeden typu fotelu. Spowodowane jest to zaniechaniem kwestii abstrakcji, nasza klasa FotelQ7 powinna wywodzić się z abstrakcji, np. z interfejsu.

Jesteśmy już blisko, ale nadal słówko kluczowe new, spaja nasze rozwiązanie z konkretna implementacją. Nie chcemy na poziomie metody tworzyć instancji obiektów, spodziewajmy się ich z wyższych warstw:

Dzięki tej prostej zmianie, nasza deska rozdzielcza nie zależy już od konkretnej implementacji, ale od jakiejś abstrakcji. Mówiąc deska rozdzielcza w tym momencie zyskała moc obsługiwania wszystkich foteli, które udostępnią jej interfejs IFotel.

Łatwe, prawda?

Podsumowanie

Zasada odwracania zależności to finał całego SOLID. Zachęca do uzależniania się od abstrakcji, a nie od konkretnych implementacji rozwiązań, jak życiowo… Innym słowy, przygotowujmy nasz kod, do obsługiwania w przyszłości tej samej ścieżki, ale za pomocą innego narzędzia. Jeszcze prościej? Polegajmy na interfejsach i klasach abstrakcyjnych, tam gdzie to wydaje się być użyteczne w przyszłości.

No właśnie, moim zdaniem każdy wpis, tutorial, etc. powinien zakończyć się kilkoma słowami o zdrowym rozsądku. Powyższe zasady, to mechanizm, który wspomaga utrzymywanie kodu w przyszłości, dzięki niemu jest trudniej, czasochłonniej teraz, ale będzie łatwiej kiedyś, dlatego osobiście uważam, że należy trzymać się złotego środka i pod odpowiednimi przesłankami, pozwolić sobie na kompromis 🙂

Więcej o wzorcu SOLID w artykule.

Dodaj komentarz