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

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

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

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

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

История

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

Цитата в одном из остатков проекта, кажется, проясняет происхождение названия: ^[3]

Деметра
Греческая богиня земледелия.
Проект «Деметра» был назван в честь Деметры, потому что мы работали на языке описания аппаратного обеспечения Zeus и мы искали инструмент для упрощения реализации Zeus. Мы искали название инструмента связано с Зевсом, и мы выбрали сестру Зевса: Деметру.
Позже мы выдвинули идею о том, что разработка программного обеспечения в стиле Demeter о развитии программного обеспечения, а не о создании программного обеспечения. Мы представили концепцию плана роста, который, по сути, последовательность все более и более сложных диаграмм классов UML.
Планы роста полезны для постепенного построения систем.

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

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

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

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

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

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

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

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

Базили и др. ^[6] опубликовал экспериментальные результаты в 1996 году, предполагая, что более низкий ответ для класса (RFC, количество методов, потенциально вызываемых в ответ на вызов метода этого класса) может снизить вероятность ошибок в программном обеспечении . Следование Закону Деметры может привести к снижению RFC. Однако результаты также показывают, что увеличение количества взвешенных методов в каждом классе ^[7] (WMC, количество методов, определенных в каждом классе) может увеличить вероятность ошибок в программном обеспечении. Следование Закону Деметры также может привести к более высокому WMC.

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

Недостатки

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

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

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

См. также

Ссылки

^ Либерхерр, К.Дж.; Голландия, IM (сентябрь 1989 г.). «Обеспечение хорошего стиля объектно-ориентированных программ» . Программное обеспечение IEEE . 6 (5): 38–48. дои : 10.1109/52.35588 . ISSN 0740-7459 . S2CID 12651917 .
^ Маседо, Эмерсон. «README.markdown: Деметра» . Гитхаб . Проверено 5 июля 2012 г.
^ «Проект Деметра - Что такое Деметра?» .
^ Бок, Дэвид. «Разносчик газет, бумажник и закон Деметры» (PDF) . Колледж компьютерных и информационных наук Северо-Восточного университета. п. 5 . Проверено 5 июля 2012 г.
^ Мец, Сэнди (2019). Практическое объектно-ориентированное проектирование: руководство по гибкому использованию Ruby (второе изд.). Аддисон-Уэсли. п. 81. ИСБН 978-0134456478 . LCCN 2018939833 .
^ Jump up to: ^а ^б Базили, Виктор; Бриан, Л.; Мело, WL (октябрь 1996 г.). «Проверка показателей объектно-ориентированного проектирования как показателей качества» (PDF) . Транзакции IEEE по разработке программного обеспечения . 22 (10): 751–761. дои : 10.1109/32.544352 . HDL : 1903/715 . Как и ожидалось, чем больше WMC, тем больше вероятность обнаружения неисправности.
^ «Взвешенные методы для каждого класса — Maisqual Wiki» . maisqual.squoring.com . Проверено 20 сентября 2018 г.
^ Jump up to: ^а ^б Эпплтон, Брэд. «Знакомство с Деметрой и ее законами» . Проверено 6 июля 2013 г. Побочным эффектом этого является то, что если вы соответствуете LoD, хотя это может значительно повысить удобство сопровождения и «адаптивность» вашей программной системы, вам также придется писать множество маленьких методов-оболочек для распространения вызовов методов на ее компоненты ( что может добавить заметные затраты времени и пространства).
^ Jump up to: ^а ^б «Расскажи, а не спрашивай» . ООО «Прагматические программисты» . Проверено 6 июля 2013 г. Недостатком, конечно, является то, что в конечном итоге вы пишете множество небольших методов-оболочек, которые мало что делают, кроме делегирования обхода контейнера и тому подобного. Компромисс по стоимости заключается между этой неэффективностью и соединением более высокого класса.
^ Либерхерр, К.; Голландия, И.; Риэль, А. (1988). «Объектно-ориентированное программирование: объективное чувство стиля» (PDF) . В Мейровице, Норман (ред.). Материалы конференции по системам, языкам и приложениям объектно-ориентированного программирования (OOPSLA '88) . АКМ. стр. 323–334. дои : 10.1145/62083.62113 . ISBN 978-0897912846 . S2CID 562521 . Проверено 5 июля 2012 г. Более простое обслуживание программного обеспечения, меньшая связь между вашими методами, лучшее сокрытие информации, более узкие интерфейсы, методы, которые легче использовать повторно, и более простые доказательства корректности с использованием структурной индукции.
^ Либерхерр, Карл; Орлеан, Дуг; Овлингер, Йохан (октябрь 2001 г.). «Аспектно-ориентированное программирование с адаптивными методами». Коммун. АКМ . 44 (10): 39–40. CiteSeerX 10.1.1.192.6403 . дои : 10.1145/383845.383855 . S2CID 2792493 . Адаптивный метод инкапсулирует поведение операции в одном месте, что позволяет избежать проблемы разброса, но также абстрагируется от структуры класса, что также позволяет избежать проблемы запутывания.

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

Либерхерр, Карл; Холланд, И. (сентябрь 1989 г.). «Обеспечение хорошего стиля объектно-ориентированных программ». Программное обеспечение IEEE . 6 (5): 38–48. дои : 10.1109/52.35588 . S2CID 12651917 .
Либерхерр, Карл Дж. (1995). Адаптивное объектно-ориентированное программное обеспечение: метод Деметры с шаблонами распространения . Издательская компания ПВС. ISBN 978-0534946029 .
Хант, Эндрю; Томас, Дэвид (2002). «5. Согни или сломай § Закон Деметры для функций» . Программист-прагматик: от подмастерья к мастеру . Аддисон-Уэсли. стр. 140–1. ISBN 978-0-13-211917-7 .
Ларман, Крейг (2005). Применение UML и шаблонов (3-е изд.). Прентис Холл. стр. 430–2. (из этой книги «Закон Деметры» также известен как «Не разговаривай с незнакомцами»)
МакКоннелл, Стив (2004). Код завершен (2-е изд.). Майкрософт Пресс. стр. 150 . ISBN 9780735619678 .
Палермо, Джеффри; Шейрман, Бен; Богард, Джимми (2009). ASP.NET MVC в действии . Публикации Мэннинга. п. 14.

Внешние ссылки

[1] Либерхерр, К.Дж.; Голландия, IM (сентябрь 1989 г.). «Обеспечение хорошего стиля объектно-ориентированных программ» . Программное обеспечение IEEE . 6 (5): 38–48. дои : 10.1109/52.35588 . ISSN 0740-7459 . S2CID 12651917 .

[2] Маседо, Эмерсон. «README.markdown: Деметра» . Гитхаб . Проверено 5 июля 2012 г.

[3] «Проект Деметра - Что такое Деметра?» .

[4] Бок, Дэвид. «Разносчик газет, бумажник и закон Деметры» (PDF) . Колледж компьютерных и информационных наук Северо-Восточного университета. п. 5 . Проверено 5 июля 2012 г.

[5] Мец, Сэнди (2019). Практическое объектно-ориентированное проектирование: руководство по гибкому использованию Ruby (второе изд.). Аддисон-Уэсли. п. 81. ИСБН 978-0134456478 . LCCN 2018939833 .

[Basili-6] Jump up to: ^а ^б Базили, Виктор; Бриан, Л.; Мело, WL (октябрь 1996 г.). «Проверка показателей объектно-ориентированного проектирования как показателей качества» (PDF) . Транзакции IEEE по разработке программного обеспечения . 22 (10): 751–761. дои : 10.1109/32.544352 . HDL : 1903/715 . Как и ожидалось, чем больше WMC, тем больше вероятность обнаружения неисправности.

[7] «Взвешенные методы для каждого класса — Maisqual Wiki» . maisqual.squoring.com . Проверено 20 сентября 2018 г.

[BradApp-8] Jump up to: ^а ^б Эпплтон, Брэд. «Знакомство с Деметрой и ее законами» . Проверено 6 июля 2013 г. Побочным эффектом этого является то, что если вы соответствуете LoD, хотя это может значительно повысить удобство сопровождения и «адаптивность» вашей программной системы, вам также придется писать множество маленьких методов-оболочек для распространения вызовов методов на ее компоненты ( что может добавить заметные затраты времени и пространства).

[Pragmatic-9] Jump up to: ^а ^б «Расскажи, а не спрашивай» . ООО «Прагматические программисты» . Проверено 6 июля 2013 г. Недостатком, конечно, является то, что в конечном итоге вы пишете множество небольших методов-оболочек, которые мало что делают, кроме делегирования обхода контейнера и тому подобного. Компромисс по стоимости заключается между этой неэффективностью и соединением более высокого класса.

[10] Либерхерр, К.; Голландия, И.; Риэль, А. (1988). «Объектно-ориентированное программирование: объективное чувство стиля» (PDF) . В Мейровице, Норман (ред.). Материалы конференции по системам, языкам и приложениям объектно-ориентированного программирования (OOPSLA '88) . АКМ. стр. 323–334. дои : 10.1145/62083.62113 . ISBN 978-0897912846 . S2CID 562521 . Проверено 5 июля 2012 г. Более простое обслуживание программного обеспечения, меньшая связь между вашими методами, лучшее сокрытие информации, более узкие интерфейсы, методы, которые легче использовать повторно, и более простые доказательства корректности с использованием структурной индукции.

[AOP-Programming-11] Либерхерр, Карл; Орлеан, Дуг; Овлингер, Йохан (октябрь 2001 г.). «Аспектно-ориентированное программирование с адаптивными методами». Коммун. АКМ . 44 (10): 39–40. CiteSeerX 10.1.1.192.6403 . дои : 10.1145/383845.383855 . S2CID 2792493 . Адаптивный метод инкапсулирует поведение операции в одном месте, что позволяет избежать проблемы разброса, но также абстрагируется от структуры класса, что также позволяет избежать проблемы запутывания.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]