Czym grozi łamanie prawa Demeter w rzeczywistości?
Jakiś czas temu natknąłem się na świetną publikację napisaną
po francusku (brak linka z powodu sklerozy i nieznajomość francuskiego, żeby
znaleźć w google). Opisywała ona sytuacje, która mi utknęła w pamięci i mam
zamiar się nią z wami podzielić.
Lecz wszystko po kolei…
Czym jest prawo Demeter?
Prawo Demeter nieformalnie można określić jako „Nie rozmawiaj z nieznajomymi”. Co idzie za tym stwierdzeniem? Otóż metoda danego obiektu może wywołać tylko metody:
- tego samego obiektu,
- dowolnego obiektu przekazanego jako parametr,
- dowolnego obiektu przez nią stworzonego,
- dowolnego składnika klasy, do której należy dana metoda.
Mnie osobiście nie podoba się określenie „Nie rozmawiaj z nieznajomymi”. Wolę o prawie Demeter myśleć w sposób: „niech twój obiekt będzie egoistyczny”. Aby zrozumieć moje podejście, musimy zrozumieć, jaki kod łamie to prawo.
Czy my, patrząc na rzeczywistość, w ten sposób jemy? Zapewne byłoby to bardziej widowiskowe, lecz niestety tak nie robimy. Jak naprawdę wygląda rzeczywistość?
w powyższym kodzie wystarczy zmienić trzecią linie kodu na:
Czy ten kod jest bardziej czytelny? Mam nadzieję drogi czytelniku, że pomyślałeś „Hell yeah”. Tak więc, co mi nie pasuję w „Nie rozmawiaj z nieznajomymi”? Otóż, zrzuca to odpowiedzialność na osobę, która wywołuję kod, a nie na autora klasy Człowiek. Gdyby klasa ta nie posiadała getterów do każdego z pola, to programista, nieważne jak niedoświadczony, nie miałby wyboru. Musiałby skorzystać z API, które dostarcza klasa, a nie kombinować. Jeżeli ty sprawisz, że „twój obiekt jest egoistyczny” - to znaczy, żeby on pokazywał innym tylko to, co chce i robił tylko to co chce - nikt go nie zmusi to wykonania dziwnej i niespójnej biznesowo akcji.
Lecz wszystko po kolei…
Czym jest prawo Demeter?
Prawo Demeter nieformalnie można określić jako „Nie rozmawiaj z nieznajomymi”. Co idzie za tym stwierdzeniem? Otóż metoda danego obiektu może wywołać tylko metody:
- tego samego obiektu,
- dowolnego obiektu przekazanego jako parametr,
- dowolnego obiektu przez nią stworzonego,
- dowolnego składnika klasy, do której należy dana metoda.
Mnie osobiście nie podoba się określenie „Nie rozmawiaj z nieznajomymi”. Wolę o prawie Demeter myśleć w sposób: „niech twój obiekt będzie egoistyczny”. Aby zrozumieć moje podejście, musimy zrozumieć, jaki kod łamie to prawo.
Człowiek stefan = new Człowiek(„Stefan”); Parówka parówka = new Parówka(); stefan.getKorpus().getZoladek().getZawartosc().add(parówka);
Czy my, patrząc na rzeczywistość, w ten sposób jemy? Zapewne byłoby to bardziej widowiskowe, lecz niestety tak nie robimy. Jak naprawdę wygląda rzeczywistość?
w powyższym kodzie wystarczy zmienić trzecią linie kodu na:
stefan.zjedz(parówka);
Czy ten kod jest bardziej czytelny? Mam nadzieję drogi czytelniku, że pomyślałeś „Hell yeah”. Tak więc, co mi nie pasuję w „Nie rozmawiaj z nieznajomymi”? Otóż, zrzuca to odpowiedzialność na osobę, która wywołuję kod, a nie na autora klasy Człowiek. Gdyby klasa ta nie posiadała getterów do każdego z pola, to programista, nieważne jak niedoświadczony, nie miałby wyboru. Musiałby skorzystać z API, które dostarcza klasa, a nie kombinować. Jeżeli ty sprawisz, że „twój obiekt jest egoistyczny” - to znaczy, żeby on pokazywał innym tylko to, co chce i robił tylko to co chce - nikt go nie zmusi to wykonania dziwnej i niespójnej biznesowo akcji.
Jeżeli się rozumiemy - czas na historię, która zmusiła mnie
do napisania tego posta.
Wyobraź sobie człowieka wchodzącego do sklepu, jest to starszy pan o imieniu Bob. Bob chodzi po sklepie, wybiera produkty, po czym podchodzi do kasy. Produkty kładzie na ladzie i czeka, aż pani kasjerka wszystko skasuje. „12.30” – powiedziała kasjerka i spojrzała na naszego bohatera. Bob bez zawahań ściągnął swoje spodnie. „CO TY ROBISZ!” – krzyknęła kasjerka i zaczęła rzucać w niego rzeczami.
Otóż widzisz drogi czytelniku, Bob tak jak wielu developerów, nie widział nic złego w tym, że odda swoje spodnie, w których był jego portfel, a w nich były pieniądze do zapłaty.
Nie bądź jak Bob, pilnuj spójności wewnątrz obiektu.
Wyobraź sobie człowieka wchodzącego do sklepu, jest to starszy pan o imieniu Bob. Bob chodzi po sklepie, wybiera produkty, po czym podchodzi do kasy. Produkty kładzie na ladzie i czeka, aż pani kasjerka wszystko skasuje. „12.30” – powiedziała kasjerka i spojrzała na naszego bohatera. Bob bez zawahań ściągnął swoje spodnie. „CO TY ROBISZ!” – krzyknęła kasjerka i zaczęła rzucać w niego rzeczami.
Otóż widzisz drogi czytelniku, Bob tak jak wielu developerów, nie widział nic złego w tym, że odda swoje spodnie, w których był jego portfel, a w nich były pieniądze do zapłaty.
Nie bądź jak Bob, pilnuj spójności wewnątrz obiektu.
Super artykuł. Pozdrawiam serdecznie.
OdpowiedzUsuńTen komentarz został usunięty przez administratora bloga.
OdpowiedzUsuń