Яким чином Закон Деметра застосовується до об'єктно-орієнтованих систем щодо зв'язку та згуртованості? [зачинено]


15

Як Закон Деметра застосовується до об'єктно-орієнтованих систем із з'єднанням та згуртованістю?

Я читав книгу "Розробка програмного забезпечення та професійна практика" і натрапив на розділ про LoD, і мені було цікаво, як цей принцип застосовується в об'єктно-орієнтованих системах.


Я колись успадкував проект, який мав високий рівень сполучення (зіркова топологія). Я очистив речі за допомогою "Шаблону посередника", щоб обмежити зв'язок між об'єктами і дозволити посереднику замість цього спілкуватися з кожним об'єктом. Незважаючи на те, що все ще є участь у з’єднанні, це обмежує кількість осіб, пов'язаних між собою. Деякі, можливо, захочуть вивчити це ще більше, якщо відчують, що у них є проблема з високою зв'язком із дизайном.
Jeach

Відповіді:


9

За словами Емерсона Маседо Закон Деметри говорить наступне:

  • Кожен підрозділ повинен мати лише обмежені знання про інші підрозділи: лише одиниці, "тісно" пов'язані з поточним підрозділом.
  • Кожен підрозділ повинен розмовляти лише зі своїми друзями; не розмовляйте з незнайомцями.
  • Поговоріть лише зі своїми найближчими друзями.

Це безпосередньо відповідає принципу низької зв'язку, як передбачається, коли подібні одиниці (або об'єкти):

  • Не бути щільно зчепленими між собою. Тільки найближчі.
  • Кожна людина повинна розмовляти лише зі своїми співробітниками, а не з колабораціоністами
  • Поговоріть лише з об'єктом негайного співпраці

Однією з найнижчих форм зв'язку є передача повідомлень, тобто дані діляться між об'єктами через виклики методу з параметрами.

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


8

Зчеплення, спрощене

Коли об'єкт викликає метод, властивість тощо іншого об'єкта, ми кажемо, що об'єкти з'єднані. Ми називаємо це з'єднанням, тому що тепер виклик нічого не може змінити щодо власного методу / опори. w.out ламаючи абонента .

Таким чином, чим більше з'єднання - методів, реквізитів. - тим складніше змінити код виклику, не порушивши весь код, який його використовує.

обмірковуючи з'єднання

  • Посилаючись навіть на одну опору, метод з'єднує два об'єкти.
  • Очевидно, з'єднання необхідне для створення програмного забезпечення.
  • Враховуючи характер з’єднання «крок блокування», ми хочемо як обмежити, так і ізолювати його. Ця мета просто іде разом із загальним розробником програмного забезпечення. принципи.
  • Чим менше об’єктів, з якими нам доведеться поговорити, тим нижня муфта.
  • Якщо мені потрібно зробити, скажімо, 20 різних викликів методу, з'єднання нижче, якщо всі 20 викликів до одного класу / об'єкта, то ці ж методи розподіляються на кілька класів / об'єктів.

Більшість знань викликає шалену зв’язок

Тут ми маємо Employeeте, Personщо має "Адреса"

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Для того, щоб отримати на вулицю , я повинен зателефонувати: myEmployee.me.home.street. Це на 180 градусів протилежне принципу найменшого знання. Я повинен знати про нутрощах, композиційної структури, з Employee, Personі Addressкласів.

Цей несправний дизайн класу змушує мене знати про всі ці класи і, таким чином, myEmployee.me.home.streetз'єднує мене (об'єкт, що викликає абонент) не менше ніж 3 класи - щоб отримати лише одну властивість!

Найменше знання врятує день

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

Додаючи всі необхідні властивості в Employeeкласі, ми фіксуємо з’єднання.

таким чином

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Дозволяє мені телефонувати: myEmployee.street-

  1. Я лише "знаю" Employee
  2. Мене поєднує лише те, Employee- наскільки б складна його структура.

Найменше знань аж донизу

Ми від'єднали свогоEEEEEEEY від Personі Address, в ідеалі, нам слід продовжувати застосовувати найменше знань, додаючи пропуск через властивості, такі, що Employeeлише спілкуються Personі Personлише розмовляють зAddress


1

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

Цінність Закону Деметра полягає в тому, що він зменшує відповіді, встановлені за визначенням. Метод об'єкта може викликати лише сам метод, будь-який параметр, переданий методу, метод будь-якого створеного ним об'єкта та метод будь-якого безпосередньо утримуваного об'єкта. Оскільки набір відповідей менший, менше шансів на високу зв’язок. Оскільки модуль / метод використовує лише безпосередні доступні посилання, то згуртованість вище


1
Дослідження ( Anquetil, N. and Laval, J. Legacy Restructuring Software: Analysis of a Concrete Case ) також продемонструвало, що зниження зв'язку та підвищення згуртованості не завжди призводять до кращої якості. Спираючись на результат одного, невеликого дослідження, що вважається шкідливим.

0

Це досить просто; скажімо, A залежить від B, а B залежить від C. Без закону Деметера ви можете використовувати і B, і C в A, але дотримуючись цього закону, A залежить тільки від B, він не може залежати від C.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.