2014-06-12 Clean Code Episode 13, The Dependency Inversion Principle

Za nami kolejna z zasad SOLID - zasada odwracania zależności. To już ostatnia zasada z tej grupy, ale obiecujemy, że to nie koniec spotkań z wujkiem Bobem!

1. Single responsibility principle
2. Open/closed principle
3. Liskov substitution principle
4. Interface segregation principle
5. Dependency inversion principle

Pogłębienie naszej wiedzy było możliwe dzięki firmie Transition Technologies, która sponsorowała odcinek. Na początku Rafał zaprezentował firmę - krótko, za to treściwie.

Wujek Bob wrócił wspomnieniami do końca lat 70 XX wieku - czasu kiedy wpadł na pomysł odwrócenia zależności. Była to epoka procesorów 8085 z 32kB RAM-u i 32kB ROM-u. Wyobrażacie to sobie?!

Wujek bob nawet to pamięta

O co chodzi z tym odwracaniem? 
Żeby to zrozumieć przyda nam się jakiś trywialny (i dość mierny) przykład - DI(los). Odwróciliśmy sobie SOLID i powstało coś w miarę sensownego - Dependency Inversion los, który nas w tym odcinku interesuje najbardziej. Tak to już jest, że czasami warto na coś spojrzeć z drugiej strony. Wiele technik i praktyk powstało dzięki takiemu założeniu (np. TDD) i podobnie jest z DI. Zejdźmy trochę głębiej w rozważaniach. Wujek wyróżnił 2 rodzaje zależności: run time oraz compile time. Zasada DI dotyczy tej drugiej - zależności czasu kompilacji.

Cash baby, cash...
W językach statycznie typowanych (takich jak Java, C#, C, C++) koszt zależności kodu źródłowego (typu compile time) jest znaczny. Kompilator musi poznać szczegóły modułów, do których się odnosimy za pomocą nazw w kodzie. Często w takim wypadku musi skompilować powtórnie wszystkie moduły zależne. Kiedyś kompilacja systemu mogła trwać nawet godziny. Dzisiaj w zasadzie moglibyśmy stwierdzić, że to nie problem - w końcu kompilatory czy to Javy czy C# są już naprawdę sprawne. Jednak ciągle czas kompilacji dużego systemu może być denerwujący - nawet jeśli trwa tylko pół minuty. Co innego jeśli weźmiemy na stół wdrożenie. Załóżmy, że zmiana w jednej klasie powoduje konieczność przebudowy wielu modułów, wtedy wszystkie musimy zdeployować - chore! Moim zdaniem jednak znacznie gorsze są utrudnienia z samym developowaniem. Załóżmy, że nad systemem pracuje większy zespół podzielony w celu rozwoju różnych komponentów. Jeśli zmiany jednego zespołu powodują konieczność kompilacji innego zespołu to mamy do czynienia z efektem opisywanym krótko - aczkolwiek zacnie - przez Pawła Włodarskiego - syf i zniszczenie.

Odwracamy...
Warto wiedzieć co jest podstawą do idei odwracania zależności. Wujek Bob wskazuje na projektowanie strukturalne (metoda top-down). Sposób zakłada rozpoczęcie dekompozycji problemu od głównej funkcji - main. Następnie projektuje się podprogramy, które mają być wywoływane przez main w celu realizacji pod-zadania. Podobnie każdy podprogram zostaje podzielony na jeszcze mniejsze podprogramy itd, aż zaprojektujemy wszystkie podprogramy konieczne do realizacji celu. Mając taki projekcik możemy zacząć pisać kod (yeah:D). Problem z tym podejściem jest taki, że zależności czasu kompilacji są dokładnie takie same jak czasu wykonania (w trakcie kompilacji wiemy, które kawałki kodu możemy wołać i potrzebujemy znać szczegóły ich implementacji).

Projektowanie strukturalne (top-down)

Wysoko-poziomowe moduły, np modelujące przypadki użycia, zależą od niżej poziomowych - szczegółów. Tego chcemy uniknąć, a z pomocą przychodzi polimorfizm. Weźmy moduł A, który woła metodę m z modułu B. Pierwotnie wygląda to mniej więcej tak:

No dobra, ale gdzie ten polimorfizm? Pomysł polega na wprowadzeniu punktu pośredniego w postaci interfejsu, który zostanie zdefiniowany w module A. Moduł A wiedziałby wtedy tylko o interfejsie i mógłby działać bez wiedzy o module B. Gadanie gadaniem, ale czas na obrazek:

Prosty zabieg, ale otrzymujemy bardzo ważną cechę. Abstrakcje w tym podejściu nie zależą od szczegółów - to szczegóły zależą od abstrakcji. Zależności czasu wykonania (A woła B) są w tym momencie w przeciwnym kierunku niż zależności czasu kompilacji (B zależy od interfejsu z A). I to ostatnie zdanie zawiera magiczne odwrócenie zależności. W drugiej części odcinka wujek Bob opowiedział jeszcze o tym jak budowali framework i jaką w nim rolę miało o DI oraz zaprezentował 2 proste przykłady.

Publika się obudziła - w końcu dostaliśmy jakiegoś koda...

SOLID by example: Flash talk Łukasza Strobina

Po zmęczonym już nieco wujku Bobie przyszedł czas na Łukasza Strobina z Transition Technologies, który zaprezentował zasady SOLID w przykładach z kodem. Dla każdej z zasad Łukasz wskazał kod naruszający jej zasady oraz rozwiązanie. W trakcie nawiązała się fajna dyskusja, padło kilka ciekawych stwierdzeń. Jedno wydaje mi się bardzo celne, że najważniejszy jest zdrowy rozsądek, czyli narzędzie, które pozwala świadomie łamać zasady.

Już za tydzień, 26 czerwca, kolejne spotkanie z Robertem Martinem dzięki firmie Seamless. Na ostatnim przed wakacjami spotkaniu wujek zaprezentuje case study zasad SOLID. Więcej o spotkaniu na meetupie. Zapraszamy, będzie jazdaaa.

PS. Dzięki za Pawłowi Włodarskiemu za zdjęcia.