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.