Zpo-4-wyk-Slajd49

Z Studia Informatyczne
Wersja z dnia 06:43, 21 sie 2006 autorstwa Bwalter (dyskusja | edycje)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacjiPrzejdź do wyszukiwania

Prawo Demeter

Prawo Demeter


Ostatni punkt wykładu nie dotyczy wprawdzie metryk, jednak także opisuje jedno z kryteriów jakości projektu obiektowego. Kryterium to zostało sformułowane w wyniku projektu Demeter i jest znane właśnie jako prawo Demeter. Dotyczy ono dopuszczalnego sposobu wiązania klas ze sobą, a więc jest powiązane z opisanymi wcześniej metrykami CBO i CF.

Problem dotyczy długich łańcuchów wywołań metod, w których poszczególne ogniwa służą do znalezienia kolejnego obiektu. Na pierwszy rzut oka taki łańcuch jest prawidłowym rozwiązaniem, ponieważ każde jego ogniwo zna tylko swojego następnika i oferuje wszystkim usługę jego zlokalizowania. Jednak istnieje jedna klasa, która jest wówczas powiązana ze wszystkimi innymi: jest nią klasa, której metoda wywołuje łańcuch metod. W przedstawionym przykładzie metoda operationsAt () jest związana z klasami Operation, Customer, Account i History, choć one między sobą nie są w żaden sposób powiązane funkcjonalnie.

Prawo Demeter opisuje sposób, w jaki należy ograniczać długie łańcuchy wywołań. Można je streścić zaleceniami "nigdy nie rozmawiaj z obcymi" i "ufaj jedynie swoim bezpośrednim przyjaciołom". W praktyce oznacza to, że obiekt powinien unikać wywoływania metod klasy, której obiekt został mu dostarczony przez inny obiekt


<< Poprzedni slajd | Spis treści | Następny slajd >>