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

редактировать
Руководство по проектированию для разработки программного обеспечения

Закон Деметры (LoD ) или принцип наименьшего знания - это руководство по дизайну для разработки программное обеспечение, в частности объектно-ориентированные программы. В общем виде LoD представляет собой частный случай слабой связи. Руководство было предложено Яном Холландом из Северо-Восточного университета в конце 1987 года, и его можно кратко резюмировать каждым из следующих способов:

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

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

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

Содержание
  • 1 История
  • 2 В объектно-ориентированном программировании
  • 3 Преимущества
  • 4 Недостатки
  • 5 См. также
  • 6 Ссылки
  • 7 Дополнительная литература
  • 8 Внешние ссылки
История

Закон восходит к 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. Если используется метод-оболочка, это означает, что объект, вызываемый через оболочку, должен был быть зависимостью в вызывающем классе.

Одним из предлагаемых решений проблемы интерфейсов расширенных классов является аспектно-ориентированный подход, в котором поведение метода определяется как аспект на высоком уровне абстракции. Широкие интерфейсы управляются с помощью языка, который определяет реализации. И стратегия обхода, и адаптивный посетитель используют только минимальный набор классов, участвующих в операции, и информация о связях между этими классами абстрагируется.

См. Также
Ссылки
Дополнительная литература
Внешние ссылки
Последняя правка сделана 2021-05-26 03:13:03
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте