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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

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

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

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

В об'єктно-орієнтованому програмуванні[ред.ред. код]

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

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

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

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

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

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

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

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

Див. також[ред.ред. код]

Посилання (англ.)[ред.ред. код]