Закон Деметры

Закон Деметры (англ. Law of Demeter, LoD) — правило дизайна при разработке программного обеспечения, в частности объектно-ориентированных программ. Обобщенно, Закон Деметры является специальным случаем слабой связности (Loose coupling). Это правило было придумано в конце 1987 в северовосточном Университете (Бостон, Массачусетс, США).

Простыми словами каждый программный модуль должен отвечать следующим требованиям:

• должен обладать ограниченным знанием о других модулях: знать о модулях, которые имеют «непосредственное» отношение к этому модулю.
• должен взаимодействовать только с известными ему модулями «друзьями», не взаимодействовать с незнакомцами.
• обращаться только к непосредственным «друзьям».

Аналогия из жизни. Если Вы хотите, чтобы собака побежала, глупо командовать ее ногами, лучше отдать команду собаке, а она уже разберется со своими ногами сама.

Основной идеей является то, что объект должен иметь как можно меньше представления о структуре и свойствах чего угодно (включая собственные подкомпоненты).

Название взято из проекта «Деметра», который использовал идеи аспектно-ориентированного и адаптивного программирования. Проект был назван в честь Деметры, греческой богини земледелия, чтобы подчеркнуть достоинства философии программирования «снизу-вверх».

В объектно-ориентированном программировании

Общее описание правила: Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C.

Более формально, Закон Деметры для функций требует, что метод М объекта О должен вызывать методы только следующих типов объектов:

• собственно самого О
• параметров М
• других объектов, созданных в рамках М
• прямых компонентных объектов О
• глобальных переменных, доступных О, в пределах М

Практически, объект-клиент должен избегать вызовов методов объектов, внутренних членов, возвращенных методом объекта-сервиса.
Для многих современных объектно-ориентированных языков программирования, использующих точку, как оператор доступа к членам класса, закон может быть перефразированная как «Используйте только одну точку».

Использование процесса внедрения зависимостей способствует^[1] соблюдению Закона Деметры.

Многоярусная архитектура может также рассматриваться, как пример реализации Закона Деметры в программной системе.
В такой архитектуре код каждого яруса может вызвать только код своего и низшего яруса. Вызов "через ярус" является нарушением многоярусной архитектуры.

Пример кода

Таким образом, код a.b.Method() нарушает Закон Деметры, а код a.Method() является корректным.

Преимущества и недостатки

Преимущества

Преимуществами Закона Деметры является то, что код разработанный с соблюдением данного закона делает написание тестов более простым^[2], а разработанное программное обеспечение менее сложно при поддержке и имеет большие возможности повторного использования кода. Так как объекты являются менее зависимыми от внутренней структуры других объектов, контейнеры объектов могут быть изменены без модификации вызывающих объектов (клиентов).

Недостатки

Недостатком Закона Деметры является то, что иногда требуется создание большого количества малых методов-адаптеров (делегатов), для передачи вызовов метода к внутренним компонентам.

Примечания

1. ↑ Внедрение зависимостей для соблюдения Закона Деметры (запись вебинара)
2. ↑ Упрощение разработки тестов для кода, соблюдающего закон Деметры (запись вебинара Google Talks с 16 минуты)

Ссылки

• Несвязность и закон Деметра. Викиучебник
• Demeter: Aspect-Oriented Software Development первоисточник англ. 
• Закон Деметры или как избежать спагетти-ассоциаций
• Связность и увязка. Закон Деметры на сайте msdn.microsoft.com
• Рассуждения о пользе закона Деметры на сайте plakhov.livejournal.com
• Пояснение на сайте blog.evseev.ru
• Описание на сайте life-prog.ru