TGViewer
Beer::Code🍺 Beer::Code🍺 @beerphp · 3.64K subscribers
Post #111 12.4K
Law of Demeter (Закон Деметры, LOD)

Этот закон часто используют вместе с темой Tell Don't Ask. Его идея в том, что объект должен обладать ограниченным знанием о других объектах и модулях, взаимодействовать только с теми, кто имеет к нему непосредственное отношение.

Формально правило звучит так, что в клиентском коде вы можете вызывать методы объектов, которые:

✅ Были переданы как аргументы;
✅ Были созданы локально;
✅ Являются глобальными;
✅ Собственные методы;

Пока что непонятно зачем это всё. Давайте разбираться.

Основная задача — создать условия для слабой связанности (loose coupling) между объектами. Но за счёт чего?

🌈 Представьте, вы находитесь в магазине, хотите купить товар стоимостью 25$. Вы дадите продавцу 25$ или вы отдадите продавцу свой кошелек, чтобы тот достал 25$? Давайте разберём этот пример.

👉 В первом случае мы явно знаем, что у объекта SomePerson есть Wallet, который мы хотим получить, чтобы достать (вычесть) из него какую-то сумму денег. Таким образом мы создаём сильную связь (tight coupling) с объектом кошелька, а также раскрываем особенности внутренней реализации.

❓ Чем же лучше второй вариант?

Когда у SomeAnotherPerson мы вызываем метод subtractMoney, это нам даёт дополнительную гибкость, возможность легко изменить внутреннюю реализацию данного метода, не изменяя другие участки кода. Как бонус появляется information hiding, а также это дело менее проблематично мокать в тестах.

🤓 LOD также называют законом "одной точки" (one dot), т.к. ноги растут из Java. В нашем же случае о его применении стоит задуматься при виде более одной стрелочки ->. Обращаю внимание, что речь идёт о методах (или свойствах), которые позволяют получить промежуточный объект, утрируя - о геттерах. То есть две стрелочки в каком нибудь fluent interface (напр. $filter->limit(10)->offset(0)) сюда не относятся.

🙈 У закона Деметры тоже есть свои минусы. Одним из них является необходимость создания большого количества методов-адаптеров. Если вы чувствуете, что классы становятся перегруженными - это признак плохого объектно-ориентированного дизайна.

❓ Можно ли нарушать закон Деметры?

Руководствуйтесь здравым смыслом. Если у вас, например, вложенные DTO, которые предназначены для транспортировки объектов, то нет никакого смысла наворачивать что-то подобное сверху. Используйте только там, где это уместно и помните о преимуществах 😉

#php #oop #middle #source
  • 👍 84
  • 🔥 20
  • ❤ 15
  • 🤯 2
  • 👎 1
More from @beerphp
  1. Sep 22, 2026Anthropic випустила Opus 5.5 За словами Anthropic, на більшості задач вона працює на рівні…
  2. Sep 21, 2026Доречі, цього тижня буду проводити НОВИЙ воркшоп Harness Engineering - 24 і 26 вересня. Од…
  3. Sep 21, 2026Хочу поділитись своєю мотивацією На тому тижні був воркшоп Agentic Engineering Workflow Ко…
  4. Sep 20, 2026Post #198
  5. Sep 14, 2026Не можу не поділитись, вчора отримав такий відгук Це прям паливо заради якого хочеться про…
  6. Sep 13, 2026І знову я зі своїм воркшопом 🙂 Але перед цим - попереджаю і кажу чесно, канал і соцмережі…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →