Закон Деметры ({gtku :ybymjd)

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

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

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

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

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

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

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

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

[править | править код]

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

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

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

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

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

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

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

Пример кода

[править | править код]

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

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

[править | править код]

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

[править | править код]

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

Недостатки

[править | править код]

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

Примечания

[править | править код]

Литература

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