Prawo Demeter to jedna z zasad dobrego programowania. Jest częścią paradygmatu SOLID. Jednak jak wyjaśnić ją bez trudnych pojęć i bez zaciemniania wyjaśnień kodem? Okazuje się, że nawet prawo programowania można opisać przykładem wziętym z życia.
Korporacja lub inna duża firma
Wyobraźmy sobie korporację lub dużą firmę z wieloma szczeblami kariery. Są w niej szeregowi pracownicy, menadżerowie niskiego, średniego lub wysokiego szczebla. Gdzieś pośrodku tego wszystkiego siedzi sobie przykładowy menadżer. Nazwijmy go Marek.
Duża firma ma strukturę hierarhiczną. Sprzątacze nie chodzą ze swoimi problemami do prezesa a ten nie każe też wykonywać pracy kierownikom niskiego szczebla. Zastanówmy się, z kim Marek będący na średnim szczeblu kariery może rozmawiać.
- Koledzy z tego samego działu (w tym również szef). Czyli po prostu wszyscy, którzy należą do jego działu.
- Jego bezpośredni podwładni. Nawet, gdy nie należą do jego działu a tworzą odrębny zespół, którym Marek zarządza.
- Osoby, które zostały mu przedstawione.
- Marek może również korzystać z zasobów swojego działu – ma dostęp do wspólnych pomieszczeń, pokoju, gdzie wszyscy siedzą. Działowego zapasu kawy, wody oraz wspólnej drukarki.
Czasem jeszcze pojawiają się ogólnodostępne zasoby jak formowy portier, szatniarka, parkingowy.
Jeśli teraz Marek będzie naszą funkcją lub metodą to widzimy już analogię. Metoda rozmawia ze swoimi kolegami (metodami tego samego obiektu). Może tworzyć nowe obiekty oraz otrzymywać obiekty w parametrach. Może też korzystać z zasobów klasy ale nie z ich podzasobów. W życiu codziennym oznaczałoby to, że Marek może korzystać ze wspólnej drukarki ale nie wolno mu jej rozkręcać aby brać jedną część.
Co daje prawo Demeter?
Jest to jedno z praw programowania obiektowego, które mają nam pomóc w tworzeniu prostego oprogramowania. Trzymając się prawa Demeter oddzielamy od siebie dalekie części kodu, które nigdy nie powinny ze sobą rozmawiać.
W praktyce programowania – powinniśmy unikać sytuacji, gdy wychodzimy poza prawo Demeter. Nasz Marek nie powinien kazać podwładnemu swojego podwładnego wykonywać żadnej pracy. ańcuch dowodzenia musi być zachowany. Możemy jedynie zlecić kierownikowi niższego szczebla zadanie, a organizacja pracy w jego zespole to już jego sprawa.
Przykładem niech będzie stos TCP/IP – struktura komunikacji jest warstwowa i głównie dzięki takiemu projektowi dzisiejszy internet działa tak sprawnie. Co by było, gdyby zamiast stosu TCP/IP ktoś zaprojektował komunikację w stylu spaghetti? Strach pomyśleć jak dziś wyglądałby internet.
Oczywiście jak wszystkie zasady – kurczowe trzymanie się tego prawa może czasem spowodować więcej szkody niż pożytku. Np. teoria Worse is better czasem może przeczyć wielu zasadom dobrego programowania. Projektując system zawsze na końcu trzeba zdać się na zdrowy rozsądek.