Prawo Demeter - (podobno) dobre praktyki programistyczne 2329 6

O temacie

Autor Wonski

Zaczęty 9.06.2016 roku

Wyświetleń 2329

Odpowiedzi 6

Wonski

Wonski

Gry (themodders@telegram)
radio engineer
posty257
Propsy91
ProfesjaProgramista
  • Gry (themodders@telegram)
  • radio engineer

Wonski
Gry (themodders@telegram)

Prawo Demeter - (podobno) dobre praktyki programistyczne
2016-06-09, 22:15(Ostatnia zmiana: 2016-06-09, 22:21)
Cześć,
Ostatnio wsiąknąłem do końca w poznawanie praktyk programistycznych. Z wieloma z nimi nie do końca się zgadzam i nie uważam ich za wygodne. Jedną z takich praktyk jest "prawo Demeter"

Krótki opis:

Nie uważam by było to wygodne w stosowaniu. Stosowanie tej praktyki powoduje, że hierarchia klas w postaci agregacji nie ma sensu, ponieważ wg tej praktyki kaskadowe odwoływanie się jest zabronione. Można to obejść, ale kosztem nadmiarowości metod, przez co interfejs staje się nieczytelny.

Możemy "rozmawiać tylko z najbliższymi przyjaciółmi", więc odwoływanie się w tym stylu:

this->_ini_file_shared_ptr->get_section(temp_name_section_shared_ptr_helper)->get_key(temp_name_key_shared_ptr_helper)-> set_key_value(temp_change_value_key_shared_ptr_helper);
odpada z wiadomych przyczyn. Zasada Demeter jest znana też jako zasada jednej kropki (w moim przypadku, wskaźnik polimorficzny), no bo występuje tylko jedno odwołanie.
Z jednej strony ma to swoje plusy, ale czy stosowanie się do tej zasady ma wymierne korzyści? Przecież to redundancja sprzeczna z metodyką LEAN.


Chciałem się Was zapytać czy warto to stosować?
Myślę, że ta zasada nie stoi na równi z takimi zasadami jak SOLID czy DRY, (nigdy, de facto, nie słyszałem o tym prawie Demeter, więc nwm czy to popularna zasada).
 

Adanos

Adanos

Administrator
Szara eminencja
posty5223
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja
Nie wydaje mi się, że stosowanie tej zasady było problemem w agregacji klas. Uważam, że ma więcej plusów niż minusów. W dużym stopniu zależy to od stylu w jakim się programuje. Są różne metodyki i trudno je wszystkie połączyć. Zawsze można wybrać te najlepsze cechy, a przy wątpliwościach się zastanowić czy ma to sens. Nie można być zbyt... sztywnym. :P

Wonski

Wonski

Gry (themodders@telegram)
radio engineer
posty257
Propsy91
ProfesjaProgramista
  • Gry (themodders@telegram)
  • radio engineer
No jest to problem, bo zamiast prostego odwołania kaskadowego, należy w klasie, która jest niżej w hierarchii dodać nową metodę, która umożliwi odwołanie do następnej klasy.

Ogromnym plusem jest to, że klasa która jest najwyżej w hierarchii nie zna klas które są znacznie niżej. Zyskujemy na modularności i kod jest znacznie bardziej elastyczny Jednak gdy dochodzi do refactoringu to mamy znacznie więcej do roboty.

W sumie to prawo Demeter to jakby rozbicie tej kaskady na całą hierarchię klas.
Napisałeś, że zależy to od stylu programowania.. mógłbyś rozwinąć?
 

Adanos

Adanos

Administrator
Szara eminencja
posty5223
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja
No jest to problem, bo zamiast prostego odwołania kaskadowego, należy w klasie, która jest niżej w hierarchii dodać nową metodę, która umożliwi odwołanie do następnej klasy.
Jakiś przykład? Wydaje mi się, że nie ma takiej potrzeby, gdy mamy dobrze zaprojektowane klasy.

Co do stylu programowania. Są różne standardy pisania kodu, nazw metod, klas. Możesz również pisać modularnie, obiektowo czy funkcyjnie. Niektórzy uważają, że singleton jest czymś fajnym, inni mają go za antywzorzec. Jedni będą stosować prawo Demeter, inni nie, bo wolą inaczej pisać. Inni lubią takie wcięcia w kodzie, a inni inne. Myślę, że nie ma co więcej rozwijać. :D

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator
Singleton jest dobry tylko w mega prostym programie albo czymś "hackowanym" na szybko / we wczesnej fazie projektu. Później przynosi niesamowite problemy. Sam jestem niesamowicie poirytowany singletonami w kodzie aplikacji do której piszę plugin. Obiekty które są przekazywane po interfejsach, mogę zastępować własnymi implementacjami. Daje mi to dużą swobodę w modyfikowaniu aplikacji bez modyfikowania jej kodu. Ale jak coś używa singletona, to nie mogę w żaden sposób zastąpić tego swoją implementacją. Singleton to zabijanie czegoś deskami. Prawo Demeter ma sporo sensu, ale nigdy nie trzymałbym się go dosłownie. Dwa poziomy w głąb są dla mnie jak najbardziej ok. Trzy to już dużo. Im więcej poziomów tym gorszy coupling miedzy klasami, a czasami my chcemy / ktoś potrzebuje po nas coś mocno pozmieniać w kodzie. Im ściślej trzymaliśmy się tego "prawa Demeter" tym mniej klas zostanie dotkniętych kiedy zmodyfikujemy interfejs którejkolwiek z nich.

Nad dużymi aplikacjami nieraz pracują dziesiątki, setki ludzi. W przypadku tej nad którą pracuję są to zespoły z wielu krajów - aktywnie pracują polacy, niemcy, rosjanie, mamy dużo do czynienia też z finami, azjatami... W czymś tak wielkim niemożliwe jest żeby programista ogarniał całość. Albo nawet dużą część całości. U nas osoby które bardzo dobrze ogarniają jeden cały komponent spośród pięciu głównych, są niemal lokalnymi bogami. Bez nich wszystko zaczęłoby się walić.
W takiej aplikacji przeciętny programista może ogarniać w jednym czasie góra kilka charakterystycznych, dobrze określonych obszarów spośród całej takiej dżungli dziesiątek i setek.
Tutaj prawo Demeter bardzo pomaga. Bo jeśli było przestrzegane, można dobrze zapoznać się z kilkoma-kilkunastoma klasami nie mając w nie wmieszanej setki innych które były przez nie pośrednio wykorzystane. Zamiast tego "po referencjach" trzeba ogarnąć tylko "o jedną klasę w głąb" poza tymi które są w obszarze który musimy poznać.

Wonski

Wonski

Gry (themodders@telegram)
radio engineer
posty257
Propsy91
ProfesjaProgramista
  • Gry (themodders@telegram)
  • radio engineer
Czyli z tego co piszesz to raczej jest sens stosowania tego na dłuższą metę.
Czy jest to standard w programowaniu? Bo raczej w profesjonalnym podejściu, wszyscy z zespołu stosują się do jednego standardu, żeby nie było chaosu w repo.
I raczej nie jest możliwe, by jedna hierarchia klas była zaprojektowana wg tego prawa a druga już nie.
Wiecie o co mi chodzi.. bo jak już pisałem, raczej nie jest to oczywisty standard jak SOLID.
 

inż. Avallach

inż. Avallach

Administrator
posty7706
Propsy5229
NagrodyV
ProfesjaProgramista
  • Administrator
Jest oczywisty, chociaż nie rozumiany dosłownie co do "głębokości 1". Znany mi raczej pod nazwą "prawo minimalnej wiedzy".
Klasa powinna wiedzieć jak najmniej. Możesz napisać ją tak żeby wiedziała tylko o tym co ma sama i co mają jej membery i parametry metod.
Programując niezgodnie z tym "prawem emeter" sprawisz że będzie zamiast tego wiedziała także o metodach typów związanych z klasami z którymi sama jest związana. Ilość wiedzy bardzo rośnie. A im większa wiedza, tym bardziej "duża, sztywna i krucha" będzie klasa. W tym sensie że zmiany w pozornie odległych klasach będą często wymuszały choćby drobne zmiany w niej. W programowaniu to niepożądane. Chcemy żeby nasza dowolna zmiana w kodzie miała jak najmniejsze i przewidywalne efekty uboczne. A nie gdzieś daleko, w czymś nie związanym z nią bezpośrednio.


0 użytkowników i 1 Gość przegląda ten wątek.
0 użytkowników
Do góry