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

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

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

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

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

История

Закон датируется 1987 годом, когда его впервые предложил Ян Холланд, работавший над проектом Demeter. Этот проект стал местом рождения многих принципов аспектно-ориентированного программирования (АОП).

Цитата в одном из фрагментов проекта, по-видимому, проясняет происхождение названия: [4]

Деметра

Греческая богиня земледелия.

Проект Demeter был назван в честь Demeter, потому что мы работали над языком описания оборудования Zeus и искали инструмент для упрощения реализации Zeus. Мы искали название инструмента, связанное с Zeus, и выбрали сестру Zeus: Demeter.

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

Планы роста полезны для постепенного создания систем.

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

Объект aможет запросить услугу (вызвать метод) экземпляра объекта b, но объект aне должен «проникать» через объект b, чтобы получить доступ к еще одному объекту, c, чтобы запросить его услуги. Это означало бы, что объект aнеявно требует большего знания bвнутренней структуры объекта.

Вместо этого bинтерфейс должен быть изменен при необходимости, чтобы он мог напрямую обслуживать aзапрос объекта, распространяя его на любые соответствующие подкомпоненты. В качестве альтернативы aможно иметь прямую ссылку на объект cи делать запрос непосредственно к нему. Если закон соблюден, только объект bзнает свою собственную внутреннюю структуру.

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

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

В частности, объект должен избегать вызова методов объекта, возвращаемого другим методом. Для многих современных объектно-ориентированных языков, которые используют точку в качестве идентификатора поля, закон можно сформулировать просто как «используйте только одну точку». [6] То есть, код a.m().n()нарушает закон там, где a.m()этого не происходит. В качестве аналогии , когда кто-то хочет, чтобы собака шла, он не командует ногам собаки идти напрямую; вместо этого он командует собаке, которая затем командует своим собственным ногам.

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

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

Basili et al. [7] опубликовали экспериментальные результаты в 1996 году, предполагая, что более низкий Response For a Class (RFC, количество методов, потенциально вызываемых в ответ на вызов метода этого класса) может снизить вероятность ошибок программного обеспечения . Следование закону Деметера может привести к более низкому RFC. Однако результаты также предполагают, что увеличение Weighted Methods per Class [8] (WMC, количество методов, определенных в каждом классе) может увеличить вероятность ошибок программного обеспечения. Следование закону Деметера также может привести к более высокому WMC.

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

Недостатки

Хотя LoD повышает адаптивность программной системы, это может привести к необходимости написания множества методов-оболочек для распространения вызовов к компонентам; в некоторых случаях это может привести к заметным временным и пространственным издержкам. [7] [9] [10]

На уровне методов LoD приводит к узким интерфейсам, предоставляя доступ только к той информации, которая ему необходима для выполнения его работы, поскольку каждому методу необходимо знать о небольшом наборе методов тесно связанных объектов. [11] С другой стороны, на уровне классов, если LoD используется неправильно, могут быть разработаны широкие (т. е. увеличенные) интерфейсы, требующие введения множества вспомогательных методов. [9] [10] Это происходит из-за плохого дизайна, а не из-за LoD как такового. Если используется метод-обертка, это означает, что объект, вызываемый через обертку, должен был быть зависимостью в вызывающем классе.

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

Смотрите также

Ссылки

  1. ^ Либерхерр, К. Дж.; Холланд, И. М. (сентябрь 1989 г.). «Обеспечение хорошего стиля для объектно-ориентированных программ». IEEE Software . 6 (5): 38–48. doi :10.1109/52.35588. ISSN  0740-7459. S2CID  12651917.
  2. ^ Маседо, Эмерсон. "README.markdown: Demeter". GitHub . Получено 05.07.2012 .
  3. ^ «Закон Деметры: принцип наименьшего знания». www.khoury.northeastern.edu . Получено 2024-11-07 .
  4. ^ «Проект Деметра — Что такое Деметра?».
  5. ^ Бок, Дэвид. «Разносчик газет, кошелек и закон Деметры» (PDF) . Колледж компьютерных и информационных наук, Северо-Восточный университет. стр. 5. Получено 05.07.2012 .
  6. ^ Метц, Сэнди (2019). Практическое объектно-ориентированное проектирование: Agile Primer Using Ruby (Второе изд.). Addison-Wesley. стр. 81. ISBN 978-0134456478. LCCN  2018939833.
  7. ^ ab Basili, Victor; Briand, L.; Melo, WL (октябрь 1996 г.). "A Validation of Object-Oriented Design Metrics as Quality Indicators" (PDF) . IEEE Transactions on Software Engineering . 22 (10): 751–761. doi :10.1109/32.544352. hdl : 1903/715 . Как и ожидалось, чем больше WMC, тем больше вероятность обнаружения неисправности.
  8. ^ "Взвешенные методы на класс - Maisqual Wiki". maisqual.squoring.com . Получено 20-09-2018 .
  9. ^ ab Appleton, Brad. "Introducing Demeter and its Laws" . Получено 6 июля 2013 г. Побочным эффектом этого является то, что если вы соответствуете LoD, то, хотя это может значительно повысить удобство обслуживания и "адаптивность" вашей программной системы, вам также придется писать множество небольших методов-оболочек для распространения вызовов методов на ее компоненты (что может добавить заметные временные и пространственные издержки).
  10. ^ ab "Tell, Don't Ask". The Pragmatic Programmers, LLC . Получено 6 июля 2013 г. Недостатком, конечно, является то, что в итоге вы пишете много маленьких методов-оберток, которые делают очень мало, но делегируют обход контейнера и тому подобное. Компромисс по стоимости заключается между этой неэффективностью и более высокой степенью связанности.
  11. ^ Либерхерр, К.; Холланд, И.; Риель, А. (1988). "Объектно-ориентированное программирование: объективное чувство стиля" (PDF) . В Мейровице, Нормане (ред.). Труды конференции по системам, языкам и приложениям объектно-ориентированного программирования (OOPSLA '88) . ACM. стр. 323–334. doi :10.1145/62083.62113. ISBN 978-0897912846. S2CID  562521 . Получено 05.07.2012 . Более простое обслуживание программного обеспечения, меньшая связанность между методами, лучшее сокрытие информации, более узкие интерфейсы, методы, которые легче использовать повторно, и более простые доказательства корректности с использованием структурной индукции.
  12. ^ Либерхерр, Карл; Орлеан, Дуг; Овлингер, Йохан (октябрь 2001 г.). «Аспектно-ориентированное программирование с адаптивными методами». Commun. ACM . 44 (10): 39–40. CiteSeerX 10.1.1.192.6403 . doi :10.1145/383845.383855. S2CID  2792493. Адаптивный метод инкапсулирует поведение операции в одном месте, тем самым избегая проблемы рассеивания, но также абстрагируется от структуры класса, тем самым избегая проблемы запутывания. 

Дальнейшее чтение

  • Либерхерр, Карл; Холланд, И. (сентябрь 1989 г.). «Обеспечение хорошего стиля для объектно-ориентированных программ». IEEE Software . 6 (5): 38–48. doi :10.1109/52.35588. S2CID  12651917.
  • Либерхерр, Карл Дж. (1995). Адаптивное объектно-ориентированное программное обеспечение: метод Деметера с моделями распространения . Издательская компания PWS. ISBN 978-0534946029.
  • Хант, Эндрю; Томас, Дэвид (2002). "5. Согнуть или сломать § Закон Деметера для функций". Прагматичный программист: от подмастерья к мастеру . Эддисон-Уэсли. стр. 140–1. ISBN 978-0-13-211917-7.
  • Ларман, Крейг (2005). Применение UML и шаблонов (3-е изд.). Prentice Hall. С. 430–2.(из этой книги «Закон Деметры» также известен как «Не разговаривай с незнакомцами»)
  • Макконнелл, Стив (2004). Code Complete (2-е изд.). Microsoft Press. С. 150. ISBN 9780735619678.
  • Палермо, Джеффри; Шейрман, Бен; Богард, Джимми (2009). ASP.NET MVC в действии . Публикации Мэннинга. п. 14.
  • Закон Деметры (LoD)
  • «Объектно-ориентированное программирование: объективное чувство стиля» (Материалы OOPSLA '88) (PDF)
  • Газетчик, кошелек и закон Деметры (PDF)
  • Фил Хаак: «Закон Деметера — это не упражнение по подсчету точек»
  • Либер: «Закон Деметры: принцип наименьшего знания»
  • «Адаптивное объектно-ориентированное программное обеспечение, метод Деметера»
  • Проект «Деметра» — Что такое «Деметра»?
Взято с "https://en.wikipedia.org/w/index.php?title=Закон_Деметры&oldid=1255999776"