Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Prawo Demeter

Prawo Demeter (ang. Law of Demeter) [1], znane także jako zasada minimalnej wiedzy (ang. Principle of Least Knowledge), jest proste i bardzo ogólne. Zastosowane do programowania obiektowego brzmi następująco:

Metoda klasy może odwoływać sie tylko do następujących typów obiektów:
  • klasy, do której należy
  • swoich parametrów
  • obiektów, które sama tworzy
  • pól klasy, do której należy, ale nie ich pól

Prawo Demeter określa zakres obiektów, do których mogą odwoływać się metody. Parafrazując prawo to doradza metodom klasy, aby rozmawiały tylko z najbliższymi przyjaciółmi. Przede wszystkim chodzi o to, by dana klasa nie znała szczegółów budowy innych klas oraz komponentów, z których sama sie składa.

Prawo Demeter zaaplikowane do programowania obiektowego pozwala unikać takich oto wywołań: car.Engine.Accelerate(). Metoda, która operuje na obiekcie car nie powinna bezpośrednio odwoływać się do komponentów z jakich składa się ten obiekt. Takie wywołanie nie tylko uzależnia od klasy obiektu car, ale również od klasy obiektu car.Engine, a my dążymy do budowania systemów luźno powiązanych, w których poszczególne elementy mogą być wymieniane bez konieczności przebudowy systemu. W przypadku takiego długiego wywołania, gdy zmieni się realizacja klasy obiektu car, prawdopodobnie trzeba będzie zmienić i ten wiersz. Mając na uwadze zasadę otwarty-zamknięty chcemy tego uniknąć.

W prawidłowej realizacji, zgodnej z prawem Demeter, klasa obiektu car powinna udostępniać metodę umożliwiającą przyspieszanie i ukrywać swoją wewnętrzną strukturę, nieudostępniając własności Engine. Z drugiej strony klienci powinni korzystać z udostępnionych im metod a nie odwoływać sie do składowych klasy. Takie postępowanie jest znane jako obudowywanie (ang. encapsulation). Na przykład: car.Accelerate();.

Przeformułowaniem prawa Demeter jest zasada mów a nie pytaj (ang. Tell Don’t Ask Principle) [2]. Zasady te zalecają, by klasy wiedziały jak najmniej (w szczególności o budowie wewnętrznej innych klas). Zasada mów a nie pytaj stwierdza, że nie powinniśmy odpytywać innych obiektów o informacje, a następnie na podstawie tych informacji podejmować decyzji. Zaleca, aby delegować odpowiedzialności do obiektów, które maja te informacje i im zlecić podjęcie decyzji. O tym jak klasom przydzielać odpowiedzialności mówią zasady przydzielania odpowiedzialności (ang. General Responsibility Assignment Software Principles, GRASP) [3].

[1] Lieberherr K.J., Holland I.: Assuring Good Style for Object-Oriented Programs. IEEE-Software, 1989, 38–48.
[2] Hunt A., Thomas D.: Pragmatyczny programista. Od czeladnika do mistrza. Warszawa. Wydawnictwa Naukowo-Techniczne, 2002.
[3] Larman C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Upper Saddle River, NJ. Prentice Hall, 2001.
Opublikowane 4 września 2007 12:54 przez nuwanda

Komentarze:

# re: Prawo Demeter

4 września 2007 23:07 by arkadiusz.wasniewski

Czy można prosić o bardziej rozbudowane i zwiększą ilością przykładów. Bardzo ciekawe, ale skąpe. Więcej czadu.

Pozdrawiam

Arek

# re: Prawo Demeter

5 września 2007 08:35 by nuwanda

Z przyjemnością pomyślę nad rozbudowaniem tego tekstu. :)

Pozdrawiam,

Bartek.

# re: Prawo Demeter

7 września 2007 22:16 by Tarciu

Osobiście zamiast "prawo Demeter" wolałbym nazwę "reguła Demeter" :)

Bo przecież to nie jest żadne prawo, tylko reguła od której są wyjątki. Nie należy się tego trzymać zbyt rygorystycznie.

Przykład pierwszy z brzegu: jak dostać się do loginu użytkownika w ASP.NET z poziomu strony?

User.Identity.Name

I to chyba nie jest przykład jakiegoś fatalnego rozwiązania.

# re: Prawo Demeter

10 września 2007 09:13 by nuwanda

Zgadzam się, prawem to nie jest i nie powinno być. Całą intencję lepiej oddaje zasada minimalnej wiedzy. Dążymy do budowania systemów luźno powiązanych, ale też nie za wszelką cenę.

# re: Prawo Demeter

10 września 2007 12:26 by ucel

Pytanie troche z innej beczki: czy te Twoja prace bedzie mozna gdzies w calosci przeczytac?

# re: Prawo Demeter

10 września 2007 13:01 by nuwanda

Generalnie jest dostępna w archiwum Instytutu Informatyki Uniwersytetu Wrocławskiego ;), ale mogę Ci ją posłać na maila.

# re: Prawo Demeter

15 września 2007 14:53 by Tarciu

Natknąłem się niedawno w artykule Martina Fowlera (http://martinfowler.com/articles/mocksArentStubs.html) na wzmiankę dotyczącą Prawa Demeter - myślę że warto przytoczyć fragment:

("mockist testers" odnosi się do programistów piszących testy jednostkowe z użyciem specyficznych obiektów określanych jako Mock)

"Mockist testers do talk more about avoiding 'train wrecks' - method chains of style of getThis().getThat().getTheOther(). Avoiding method chains is also known as following the Law of Demeter. While method chains are a smell, the opposite problem of middle men objects bloated with forwarding methods is also a smell. (I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter.)"

Komentarze anonimowe wyłączone