Попробую и я ответить. Закон применять надо всегда, если есть возможность его применить.
Немного лирики: та тонна бизнес-кода 20-30 разработчиков, которая прошла через меня позволила познать тот самый дзен Clean Code, не могу сказать, что у нас все везде хорошо, но за последние несколько лет мы так улучшили его общее состояние, что с ним становится приятно работать — и это передается от разработчика к разработчику, вселяя уверенность, понимание и осознание каждого участка кода.
При чем здесь правило Деметры? Оно и дает эти возможности. Как вы думаете, почему так популярен IoC и DIC Symfony2 на его основе? Своей популярностью он как раз обязан тем, что использует неявно правило Деметры для всех создаваемых сервисов: каждый сервис в контейнере получает только свои зависимости и не лезет через них к другим, более того, сам контейнер зависимостей — отражение правила Деметры, потому что он пользуется исключительно своими методами для создания инстансов сервисов, обращению к параметрам.
Идем дальше, слои приложения. Если кто не знает — учите мат.часть. Но если кратко, то слой данных не должен содержать бизнес-логики и взаимодействует с уровнем сервисов. Уровень сервисов содержит необходимую логику и предоставляет API наружу для контроллеров, веб-сервисов и других, но не отвечает за поддержку различных форматов запросов/ответов. Уровень контроллеров позволяет распаковывать запросы/упаковывать ответы, работая только с уровнем сервисов, не делая никаких предположений об источнике данных. Где здесь правило Деметры? Ответ очевиден: везде. Если мы соблюдаем это правило, то мы можем независимо менять реализацию кажого из слоев, не волнуясь о том, что сломается что-то в слое, который мы не трогаем сейчас.
Следующий пункт: уровень детализации участка кода. Если вы проводили ревью кода, то как часто вам приходилось думать о том, что делает конкретный участок кода с этой цепью вызовов внутри? Есть простой факт, что мы можем держать в голове эффективно около 7 объектов, когда идет ревью кода, то каждый уровень цепочки обязует загрузить себе в память лишний класс, потому что только так вы поймете что происходит в конечном счете. Проведем легкую арифметику: если у нас есть класс, он же сервис, в который инжектятся три других сервиса, то у нас пока в памяти 4 сущности, которые мы легко понимаем. Дальше идет вызов метода с аргументами, если этот метод принимает три параметра и работает только с прямыми зависимостями на один уровень, то все хорошо: 7 объектов, но все еще понятно, как оно работает. Но как только начинаются запросы вида $this->service->createResult($request)->translate($mapping); приходится материться, так как такой код не помещается со всеми зависимостями в наше ОЗУ — мозг эффективно. Отсюда вывод — каждый участок кода отвечает за свой уровень детализации, позволяя более низким сервисам раскрывать детали. Если мне понадобятся детали — я дойду до них, но они не должны мне мешать понимать текущий код уровнем выше, а для этого надо вызывать только свои соседей, делегируя детали все ниже и ниже.
Надеюсь, мои мысли подтолкнут вас к добрым намерениями )
