Еще в 1997 году А. Шарп сформулировал такой принцип:
📃 Процедурный код сначала получает информацию, а затем принимает решения. Объектно-ориентированный код говорит объектам, что нужно делать.
То, что мы принимаем решения за пределами объектов — нарушает их information hiding. В этом примере мы скрыли детали реализации. Это упростило понимание и поддержку нашего кода, а также сделало наш объект более осознанным.
❗️ Внимание, обычно в этом месте кто-то вспоминает про "анемичную модель", а кто-то про "god objects" и начинается дикий срач, так что будьте готовы, если хотите с кем-то обсудить эту тему ;)
👉 Принципы — это не истина последней инстанции. Безусловно, мы должны держать TDA в голове, но не слепо ему следовать. Да он может привести к:
🔹 Раздутию классов и увеличения их сложности;
🔹 Увеличению coupling из-за того что у объекта много ответственности;
🔹 Нарушению SRP (single responsibility principle) в конце концов;
❓ С другой стороны, если для регистрации
User вам нужны только email и password, которые совсем не принимают участия в других процессах, то действительно ли всё должно быть в одном объекте? Или это совсем другой объект напр. Credentials? Конечно многое зависит от задачи и контекста, но в любом случае стоит придерживаться здравого смысла.
#oop #middle #source
