Мое понимание последствий Закона Деметры, кажется, отличается от понимания DrJokepu - всякий раз, когда я применяю его к объектно-ориентированному коду, это приводит к более тесной инкапсуляции и связности, а не к добавлению дополнительных методов получения к путям контракта в процедурном коде .
В Википедии действует правило
Более формально, закон Деметры для
функции требует, чтобы метод М
объект O может вызывать только
методы следующих видов
объекты:
- О себе
- Параметры М
- любые объекты, созданные / созданные в M
- Объекты прямого компонента O
Если у вас есть метод, который использует «кухню» в качестве параметра, Деметер говорит, что вы не можете проверять компоненты кухни, а не то, что вы можете проверять только непосредственные компоненты.
Написание набора функций только для удовлетворения закона Деметры, как это
Kitchen.GetCeilingColour()
просто выглядит для меня как пустая трата времени и на самом деле это мой способ добиться цели
Если метод за пределами Kitchen передан кухне, по строгому Demeter он также не может вызывать какие-либо методы в результате получения GetCeilingColour () для него.
Но в любом случае, смысл состоит в том, чтобы удалить зависимость от структуры, а не перемещать представление структуры из последовательности связанных методов в имя метода. Создание таких методов, как MoveTheLeftHindLegForward () в классе Dog, ничего не делает для выполнения Demeter. Вместо этого вызовите dog.walk () и дайте собаке справиться со своими ногами.
Например, что если требования изменятся, а мне понадобится высота потолка?
Я бы реорганизовал код, чтобы вы работали с комнатой и потолком:
interface RoomVisitor {
void visitFloor (Floor floor) ...
void visitCeiling (Ceiling ceiling) ...
void visitWall (Wall wall ...
}
interface Room { accept (RoomVisitor visitor) ; }
Kitchen.accept(RoomVisitor visitor) {
visitor.visitCeiling(this.ceiling);
...
}
Или вы можете пойти дальше и полностью исключить геттеры, передав параметры потолка методу visitCeiling, но это часто приводит к хрупкому соединению.
Применяя его к медицинскому примеру, я ожидаю, что SolvedAdminstrationRoute сможет подтвердить лекарство или, по крайней мере, вызвать метод validateForSolvedAdministration, если в классе лекарства есть информация, необходимая для проверки.
Однако Demeter применяется к ОО-системам, где данные инкапсулированы в объектах, которые работают с данными, а не в той системе, о которой вы говорите, которая имеет разные слои, данные передаются между слоями в тупых, ориентированных на навигацию структурах. , Я не вижу, что Demeter обязательно может применяться к таким системам так же легко, как к монолитным или основанным на сообщениях. (В системе, основанной на сообщениях, вы не можете перейти к чему-либо, что не содержится в граммах сообщения, поэтому вы застряли с Demeter, нравится вам это или нет)