Preferuj polimorfizm zamiast if/else czy switch/case
Przed użyciem switch’a zastanów się nad użyciem polimorfizmu, ponieważ wujek Bob przyjmuje zasadę, “jednego switcha”. Czyli jeden switch umieszczony w fabryce. Powinien on tworzyć obiekty polimorficzne, ponieważ zastępują one switch’e w innych miejscach aplikacji.
Rozdziel kod wielowątkowy
Staraj się trzymać te kody oddzielnie, ponieważ zasadniczo się różnią. Różnią się pod względem pisania, utrzymywania, debugowania, ponieważ kiedy wystąpi problem łatwiej jest działać.
Prawo Demeter a wstrzykiwanie zależności
Wstrzykiwanie zależności pozwala na oddzielenie konfiguracji – tworzenia zależności od obiektu, ponieważ obiekt powinien zlecić czemuś większemu (kontenerowi) odpowiedzialność tworzenia ich.
Obiekt zazwyczaj udostępnia tylko konstruktor. Natomiast kontener zajmuje się resztą. Spring Framework – znany przykład kontenera zajmującego się wstrzykiwaniem zależności.
Prawo Demeter w praktyce
Mówi o tym, z jakimi obiektami dana klasa może się komunikować z następującymi obiektami:
- przekazanymi jako parametr wejściowy
- stanowiącymi bezpośrednio pole danej klasy
- dostępnymi globalnie
- stworzonymi przez daną metodę
Paweł Pluta fajnie przedstawił prawo Demeter (poniższszy przykład): link
Przykład łamiący prawo Demeter. Przedstawiający strukturę firmy. Company ma wiele Depratment’ów. Department ma wiele Team’ów. Team’y mają Members’ów – pracowników.
Spróbujmy obliczyć sumę wynagrodzeń na departament. Poniżej widzimy jak klasa Company wie wszystko(źle). Zna całą strukturę aż do najmniejszego członka – pracownika. Złamane prawo Demeter, ponieważ według niego powinna mieć dostęp tylko do klasy Department, ale nie dalej.
W takim przypadku jedna zmiana spowoduje, że będziemy musieli zmieniać w wielu miejscach. Wykorzystując prawo Demeter musielibyśmy sprawdzić tylko bezpośrednich sąsiadów, ponieważ w tym przypadku tylko klasę Department.
Co można zrobić? Wydelegować obliczanie kosztów do Department’u. Tak naprawdę Department’y mogą inaczej wyliczać wynagrodzenie. Dlatego to dobre podejście.
Poniżej widać, że klasa Company korzysta tylko z metod Department. W związku z tym dzięki przestrzeganiu Demeter, klasa odwołuje się wyłącznie do obiektów, które dobrze zna pod względem wewnętrznej struktury.
Obliczanie wynagrodzenia przenieśliśmy do Deparment’u.
Pisanie kodu spełniającego prawo Demeter, może ulepszyć modyfikowalność i elastyczność projektu. Testowanie i analiza błędów jest utrudniona, gdy klasa wie wszystko.
W paradygmacie zorientowanym obiektowo obiekty mają informować inne obiekty, co mają robić — delegować, zamiast pytać o dane od innych i robić wszystko samemu.
Prawo Demeter, a ilość kropek
Jeśli dana linijka kodu zawiera więcej niż jedną kropkę to znaczy, że kod odwołuje się do zbyt dalekich obiektów. Trzeba się nad nim zastanowić.
A czy Fluent API (dużo kropek) przestrzega prawa Demeter? Tak, bo działamy na tym samym obiekcie. Dlatego ok. Poniżej przykład:
Struktury danych, które nie posiadają zachowań mogą być zwolnione z prawa Demeter!
Ważne! W przestrzeganiu prawa Demeter kieruj się zdrowym rozsądkiem. Jak zawsze. Bądź pragmatycznym programistą.
Źródła:
https://pawelpluta.com/the-law-of-demeter-by-example/
http://www.pzielinski.com/?p=1391
