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

У слова «Деметра» есть и другие значения; см. Деметра.

Закон Деметры (англ. Law of Demeter, LoD) — набор правил проектирования при разработке программного обеспечения, в частности объектно-ориентированных программ, накладывающий ограничения на взаимодействия объектов (модулей). Обобщенно, закон Деметры является специальным случаем слабой связанности (англ. loose coupling).

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

Говоря упрощённо, каждый программный модуль:

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

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

Правила были предложены в конце 1987 в северо-восточном Университете (Бостон, Массачусетс, США). Название взято из проекта «Деметра», который использовал идеи аспектно-ориентированного и адаптивного программирования. Проект был назван в честь Деметры, греческой богини земледелия, чтобы подчеркнуть достоинства философии программирования «снизу-вверх».

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

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

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

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

Практически, объект-клиент должен избегать вызовов методов объектов, внутренних членов, возвращенных методом объекта-сервиса.

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

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

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

Пример кода

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

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

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

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

Недостатки

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

Литература

• Стив Макконнелл. Совершенный код = Code Complete. — Русская Редакция, Питер, 2005. — С. 31. — 896 с.
• Vaughn Vernon. Implementing Domain-Driven Design. — Addison-Wesley Professional, 2013. — ISBN 9780133039900.

Ссылки

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