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

Закон Деметри (англ. Law of Demeter, LoD) — правило дизайну під час розробки програмного забезпечення, зокрема об'єктно-орієнтованих програм. Узагальнено, Закон Деметри є окремим випадком слабкої зв'язності. Правило було винайдено у Північносхідному Університеті (Бостон, Массачусетс, США) наприкінці 1987 та може бути сформульоване одним з таких способів:

• Кожен модуль має володіти обмеженим знанням про інші модулі: тільки про модулі, які мають «близьке» відношення до даного модуля.
• Кожен модуль має розмовляти тільки зі своїми друзями, не розмовляти з незнайомцями.
• Звертатись тільки до безпосередніх друзів.

Головною ідеєю є те, що об'єкт повинен мати якнайменше уявлення про структуру та властивості чого завгодно (включно з власними підкомпонентами).

Назва походить з проєкту «Деметра», що використовував ідеї аспектно-орієнтованого та адаптивного програмування. Проєкт було названо на честь Деметри, грецької богині землеробства, щоб підкреслити переваги філософії програмування «знизу-нагору».

В об'єктно-орієнтованому програмуванні

У контексті об'єктно-орієнтованого програмування, Закон Деметри більш точно називати «Закон Деметри для функцій/методів». У цьому разі, об'єкт А може використовувати сервіс (викликати метод) об'єкта B, та об'єкт А не може «через» об'єкт В отримати доступ до іншого об'єкта, С, та використовувати його сервіси. Якби це було можливо, це значило б, що об'єкт А явно потребує більшого знання про внутрішню структуру об'єкта В.

Замість цього, інтерфейс В має бути змінено, якщо необхідно, таким чином, щоб напряму оброблювати запити об'єкта А, передаючи їх відповідним підкомпонентам. Як альтернатива, А може мати пряме посилання на об'єкт С та викликати методи безпосередньо з нього. Якщо дотримуватися закону, тільки об'єкт В знає свою внутрішню структуру.

Більш формально, Закон Деметри для функцій вимагає, що метод М об'єкта О має викликати методи тільки наступних типів об'єктів:

1. власне самого О
2. параметрів М
3. будь-яких об'єктів, створених у межах М
4. прямих компонентних об'єктів О
5. глобальних змінних, доступних О, у межах М

Практично, об'єкт-клієнт має уникати викликів методів об'єктів, внутрішніх членів, повернених методом об'єкта-сервісу. Для багатьох сучасних об'єктно-орієнтованих мов програмування, що використовують крапку, як кваліфікатор члена класу, закон може бути перефразовано як «Використовуйте лише одну крапку». Таким чином, код a.b.Method() порушує Закон Деметри, а код a.Method() є коректним.

Переваги та недоліки

Перевагами Закону Деметри є те, що розроблене програмне забезпечення є менш складним під час підтримки та більші можливості повторного використання коду. Так як об'єкти є менш залежними від внутрішньої структури інших об'єктів, контейнери об'єктів можуть бути змінені без модифікації викликаючих об'єктів (клієнтів).

Недоліком Закону Деметри є те, що іноді потребує створення великої кількості малих методів-адаптерів (делегатів), для передачі викликів методу до внутрішніх компонентів. Більше того, інтерфейс класу може стати перевантаженим, так як вміщує методи внутрішніх класів, що порушує принцип високої зв'язності. Та це також може бути сигналом поганого об'єктно-орієнтованого дизайну.

Багатоярусна архітектура може розглядатися, як приклад імплементації Закону Деметри у програмній системі. У такій архітектурі код кожного з ярусів може викликати тільки код свого ярусу та код з нижчого ярусу. Виклик «через ярус» є порушенням багатоярусної архітектури.

Див. також

• Мова програмування
• Програмування
• Об'єктно-орієнтоване програмування
• Шаблони проєктування програмного забезпечення

Посилання (англ.)

• Simple Law of Demeter in Ruby/Rails with demeter gem
• Brad Appleton: “Introducing Demeter and its Laws”
• Law of Demeter (Web site)
• “Object-Oriented Programming: An Objective Sense of Style” (OOPSLA '88 Proceedings) (PDF)
• Law of Demeter applied to Ruby on Rails
• The Paperboy, The Wallet,and The Law Of Demeter (PDF)
• Phil Haack: «The Law of Demeter is not a Dot Counting Exercise»
• Lieber: «Phil Holland's Law of Demeter»