IQ>Звучит эпически, а как быть со stateless объектами в которых одна логика и нет состояния? Для чего им DI, если потенциальное время их жизни — от старта системы до самого ее финиша?

Звучит не эпически а логично. Statefull или Stateless абсолютно никак не влияет на то надо ли обьект инжектить. Единственное на что это влияет — на время жизни обьекта. Если он Stateless — его смело можно делать singleton-ом. Что касается Statefull то надо разбираться что за стейт и кому он принадлежит. А у вас в голове каша, вы смешали разные понятия — State-а, и DI. На вопрос для чего — уже обьяснял, для того что бы иметь возможность подменять в тестах, для того что бы сделать зависимость явной.


Tom>>Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.

Tom>>1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.

IQ>Забавно ))) вот например время жизни db entity определяется оно как правило контекстом внутри одного метода от загрузки из БД до сохранения в БД. Вот например есть ворох статических хелперных методов не имеющих состояния. Вот например есть целые сервисы, зависимость от которых и жизни которых определяется контекстом бизнес операции т.к. сильно зависит от бизнес логики...
Спросить то чего хотел. И ещё раз уточню, забавно выглядит тут ваша позиция неофита. Могу спорить вы возрастной программист лет после 40-ка которые просто не смог в DI. И уже никогда не сможет.

IQ>Мне кажется или ваша позиция больше связана с вопросами веры, чем с вопросами разработки ПО?
Вам кажется. Моя позиция связана с принципами и опытом разработки mission critical систем работающих 24/7 и распространяющихся по схеме PaaS. Качество для нас критически важно. Покрытие тестами для нас критически важно.

Tom>>2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.

IQ> Э... четко определить зависимости исключительно в рамках конкретной реализации DI которые качественно более примитивные, чем могут быть рамки бизнес операции. Собственно, когда DI перестает использоваться новичками исключительно для хелперных методов, проблемы с ним связанные и начинают всплывать.
Мда. Вы научитесь писать стройно и понятно. А то у вас каша не только в голове а и в сообщениях. И когда пишете чётко определяйтесь что именно хотите сказать.

Tom>>3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.

IQ>А вы не задумывались откуда может взяться понимание, что есть сервис, а что нет на старте проекта? А ведь DI религиозные фанатики начинают использовать в самом начале. Ах да... Tom — "Всё остальное — DI." Т.е. вообще все прямо с самого старта и есть цель для DI... Colonoscopy Injection детектед В общем мой пост как раз про это.

Tom>>В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.

IQ> У меня полно опыта в области DI. Я отхреначивал DI нафиг уже в трех проектах потому как с ним архитектура типа big ball of mud становиться абсолютно неподдерживаемой.
С чем вас и поздравляю. Отхреначивайте дальше. И к архитектуре DI не имеет никакого отношения. DI это маленькая частная практика наряду с кучей других практик которые необходимы для того что бы писать качественный код. А то что вы делает называется "макароны"