Закон Деметры (LoD ) или принцип наименьшего знания - это руководство по дизайну для разработки программное обеспечение, в частности объектно-ориентированные программы. В общем виде LoD представляет собой частный случай слабой связи. Руководство было предложено Яном Холландом из Северо-Восточного университета в конце 1987 года, и его можно кратко резюмировать каждым из следующих способов:
Фундаментальное представление состоит в том, что данный объект должен как можно меньше предполагать структуру или свойства чего-либо другого (включая его подкомпоненты), в соответствии с принципом «сокрытие информации ». Его можно рассматривать как следствие принципа наименьших привилегий, согласно которому модуль обладает только информацией и ресурсами, необходимыми для его законной цели.
Он назван так из-за его происхождения, и аспектно-ориентированное программирование. Проект был назван в честь Деметры, «матери-распределителя» и греческой богини сельского хозяйства, что означает восходящий философия программирования, которая также воплощена в самом законе.
Закон восходит к 1987 году, когда он был впервые предложен Яном Холландом, который работал над. Именно здесь зародилось множество принципов АОП (аспектно-ориентированное программирование).
Цитата в одном из остатков проекта, кажется, проясняет происхождение названия:
Сельское хозяйство
Греческая богиня земледелия.
Проект Demeter был назван в честь Деметры, потому что мы работали над языком описания оборудования Zeus и искали инструмент для упрощения реализации Zeus. Мы искали название инструмента, связанное с Зевсом, и выбрали сестру Зевса: Деметру.
Позже мы продвигали идею о том, что разработка программного обеспечения в стиле Деметры - это развитие программного обеспечения, а не создание программного обеспечения. Мы представили концепцию плана роста, который в основном представляет собой последовательность все более сложных диаграмм классов UML.
Планы роста полезны для постепенного создания систем.
— Проект Demeter - что такое Demeter?Объект a
может запросить услугу (вызвать метод) экземпляра объекта b
, но объект a
не должен «проходить через» объект b
для доступа к еще одному объекту, c
, чтобы запросить его услуги. Это будет означать, что объект a
неявно требует большего знания внутренней структуры объекта b
.
Вместо этого интерфейс b
следует при необходимости изменить, чтобы он мог напрямую обслуживать запрос объекта a
, распространяя его на любые соответствующие подкомпоненты. В качестве альтернативы, a
может иметь прямую ссылку на объект c
и делать запрос непосредственно к нему. При соблюдении закона только объект b
знает свою внутреннюю структуру.
Более формально закон Деметры для функций требует, чтобы метод m
объекта a
мог вызывать только методы следующих видов объектов:
a
сам; параметрыm
;m
;a
;a
в области m
.В частности, объект должен избегать вызова методов объекта, возвращаемого другим методом. Для многих современных объектно-ориентированных языков, в которых точка используется в качестве идентификатора поля, закон можно сформулировать просто как «используйте только одну точку». То есть код a.m (). N ()
нарушает закон, а a.m ()
- нет. В качестве аналогии, когда кто-то хочет, чтобы собака гуляла, он не приказывает ногам собаки идти прямо; вместо этого человек командует собакой, которая затем командует своими ногами.
Преимущество следования Закону Деметры состоит в том, что получаемое программное обеспечение имеет тенденцию быть более поддерживаемым и адаптируемым. Поскольку объекты в меньшей степени зависят от внутренней структуры других объектов, контейнеры объектов можно изменять без переделки вызывающих их объектов.
Basili et al. опубликовал экспериментальные результаты в 1996 году, предполагающие, что более низкий ответ для класса (RFC, количество методов, потенциально вызываемых в ответ на вызов метода этого класса) может снизить вероятность программных ошибок. Следование закону Деметры может привести к снижению RFC. Однако результаты также предполагают, что увеличение взвешенных методов для каждого класса (WMC, количество методов, определенных в каждом классе) может увеличить вероятность ошибок программного обеспечения. Следование Закону Деметры также может привести к более высокому WMC; см. Недостатки.
A многоуровневая архитектура может рассматриваться как систематический механизм для реализации закона Деметры в программной системе. В многоуровневой архитектуре код внутри каждого уровня уровня может вызывать только код внутри уровня и код на следующем уровне ниже. «Пропуск слоев» нарушит многоуровневую архитектуру.
Хотя LoD увеличивает адаптивность программной системы, это может привести к необходимости написания множества методов оболочки для распространения вызовов на компоненты; в некоторых случаях это может добавить заметные временные и пространственные издержки.
На уровне метода LoD ведет к узким интерфейсам, предоставляя доступ только к той информации, которая необходима для выполнения своей работы, поскольку каждый метод требует знать о небольшом наборе методов близкородственных объектов. С другой стороны, на уровне класса, если LoD используется неправильно, могут быть разработаны широкие (т. Е. Увеличенные) интерфейсы, которые потребуют введения множества вспомогательных методов. Это происходит скорее из-за плохой конструкции, чем из-за самого LoD. Если используется метод-оболочка, это означает, что объект, вызываемый через оболочку, должен был быть зависимостью в вызывающем классе.
Одним из предлагаемых решений проблемы интерфейсов расширенных классов является аспектно-ориентированный подход, в котором поведение метода определяется как аспект на высоком уровне абстракции. Широкие интерфейсы управляются с помощью языка, который определяет реализации. И стратегия обхода, и адаптивный посетитель используют только минимальный набор классов, участвующих в операции, и информация о связях между этими классами абстрагируется.