Здравствуйте, Tom, Вы писали:

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

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

Опять эти тесты... несовершенная технология тестирования в ответе за уничтожение мозгов огромного количества разработчиков. Сегодня уже есть технологии позволяющие не ломать архитектуру исходя из потребностей тестирования.

Если бы вы прочитали сам пост, то несомненно увидели бы, что я описываю ситуацию, когда тесты в проекте — это несбыточная фантазия.

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

Я в посте все написал — я лично не встречал проектов, где DI был обоснованно использован. Увы мне, увы моей конторе. Мы клепаем бизнес логику, тоннами. Может где-то оно иначе, мой пост не против DI, а против его использования в религиозных целях.

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

Спрошу прямо — вы на каком курсе института?

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

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

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

Tom>С чем вас и поздравляю. Отхреначивайте дальше. И к архитектуре DI не имеет никакого отношения. DI это маленькая частная практика наряду с кучей других практик которые необходимы для того что бы писать качественный код. А то что вы делает называется "макароны"

Если бы вы прочитали пост, то сообразили, что именно про это там и написано И собственно проблема о которой я заявляю в том, что "маленькая частная практика DI" в силу своей формальности, доминирует над всеми другими практиками. Что использование DI не делает архитектуру автоматически хорошей А вот г...код делает на порядок более многословным и сложным.

PS И к архитектуре DI не имеет никакого отношения.

Т.е. по вашему использование механизмов DI никак не влияет на архитектуру системы?