Когда я узнал об этих принципах, гибкость моего кода, по ощущениям, выросла х2, а скорость принятия решения по дизайну сущностей х5.
Если SOLID – это набор принципов написания качественного кода, то Law of Demeter (LoD) и Tell Don’t Ask (TDA) – это конкретные приемы как добиться SOLID.
Сегодня поговорим про Law of Demeter («Закон Деметры»).
Это принцип помогает определиться: «Как я буду получать / изменять вложенные объекты» – применим в языках, где можно определить «классы» со свойствами и методами.
Часто складывается ситуация, когда мы откуда-то (например, из HTTP запроса) получили id сущности `a`, пошли за ней в БД и из сущности `a` нам надо получить / изменить сущность `b` вызвав метод `Method`.
Так вот Википедия гласит:
У Пользователя есть Посты, в которых есть Комментарии. Вы хотите получить «Комментарии последнего Поста».
Можно запилить такое:
Если SOLID – это набор принципов написания качественного кода, то Law of Demeter (LoD) и Tell Don’t Ask (TDA) – это конкретные приемы как добиться SOLID.
Сегодня поговорим про Law of Demeter («Закон Деметры»).
Утрированно
Это принцип помогает определиться: «Как я буду получать / изменять вложенные объекты» – применим в языках, где можно определить «классы» со свойствами и методами.
Часто складывается ситуация, когда мы откуда-то (например, из HTTP запроса) получили id сущности `a`, пошли за ней в БД и из сущности `a` нам надо получить / изменить сущность `b` вызвав метод `Method`.
Так вот Википедия гласит:
Код `a.b.Method()` нарушает Закон Деметры, а код `a.Method()` является корректным.
Пример
У Пользователя есть Посты, в которых есть Комментарии. Вы хотите получить «Комментарии последнего Поста».
Можно запилить такое: