Гений Закона Деметры

Давайте глубоко погрузимся в то, что он говорит, что это на самом деле означает, и как подчиняться этому в букве и духе.

Почему мы должны подчиняться закону Деметры?

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

То же самое можно сказать и о других концепциях, таких как Принцип Единой Ответственности или Принцип Открытого / Закрытого и т. Д. Они допускают очень широкий запас толкования, поэтому практичность, прямая полезность, поэтому уменьшается.

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

Так что это говорит?

Закон в его первоначальной форме сформулирован так:

Для всех классов C и для всех методов M, связанных с C, все объекты, которым M отправляет сообщение, должны быть

• Объекты аргумента М, включая объект самообслуживания или
• Объекты переменных экземпляра C

(Объект, созданный M, или функциями или методами, которые вызывает M, и объекты в глобальных переменных рассматриваются как аргументы M.)

В первые дни объектно-ориентирования объекты должны были «отправлять сообщения» друг другу. Вот как они общались. Таким образом, термин «объекты, которым M отправляет сообщение» примерно переводится как «объекты, используемые M», или в более практическом определении «объекты, для которых M вызывает метод».

Вы могли заметить, что в скобках после двух правил есть несколько очень важных дополнительных моментов. Они кажутся разъяснениями, упомянутыми просто мимоходом, но на самом деле они являются дополнительными правилами. Итак, давайте переформулируем весь Закон, чтобы все пункты стояли независимо друг от друга:

Для всех классов C и для всех методов M, связанных с C, все объекты, которым M отправляет сообщение, должны быть:

1. self( thisна Java)
2. Объекты аргумента М
3. Переменные экземпляра объектов C
4. Объекты, созданные M, или функциями или методами, которые вызывает M
5. Объекты в глобальных переменных ( staticполя в Java)

Что это означает?

Ну, закон формулирует то, что нам разрешено делать любым конкретным методом М. Итак, давайте вернемся назад и выясним, что именно запрещает этот закон .

Правило № 4 гласит, что все объекты, созданные во время вызова M, прямо или косвенно, разрешены. Таким образом, запрет должен быть среди объектов, которые уже существовали, когда начался вызов.

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

Правила № 1, № 2 и № 3, кроме того, допускают «Я», параметры М и все объекты в переменных экземпляра С.

Это означает, что Закон запрещает «отправку сообщения» любому уже существующему объекту, который хранится в переменных экземпляра других классов, если только он не хранится нашим классом или не передается нам в качестве параметров метода.

Примеры

Давайте посмотрим на некоторые примеры Закона в действии:

public final class NetworkConnection {
    public void close() {
        sendShutdownMessage(); // Allowed?
    }
    private void sendShutdownMessage() {
        ...
    }
}

public final class NetworkConnection {
    private Socket socket;

    public void close() {
        socket.close(); // Allowed?
    }
}

public final class NetworkConnection {
    public void send(Person person) {
        sendBytes(person.getName().getBytes());
        sendBytes(person.getPhoto().getBytes();
        ...
    }
}

car.getOwner().getAddress().getStreet();

Owner owner = car.getOwner();
Address ownerAddress = owner.getAddress();
Street ownerStreet = ownerAddress.getStreet();

Report report = new ReportBuilder()
  .withBorder(1)
  .withBorderColor(Color.black)
  .withMargin(3)
  .withTitle("Law of Demeter Report")
  .build();

car.getOwner().getAddress().getStreet(); // This is a violation

car.getOwnerAddressStreet(); // This is a proposed "solution"

public final class Car {
    private final Owner owner;

    public Street getOwnerAddressStreet() {
        return owner.getAddressStreet();
    }
    ...
} 

car.getOwner().getAddress().getStreet();

car.owner.address.street; // Using direct access to fields

public final class Car {
    private final Owner owner;

    public Owner getOwner() {
        return owner;
    }
} 

public final class Garage {
    public void isAllowed(Car car) {
        Owner owner = car.getOwner(); // Allowed?
        ...
    }
}