VK
Size: a a a
2017 December 26
SK
Их никто сейчас отдельно в дескрипторах не прописывает
Ну да - вместо этого теперь везде ставят автовайринг и поди там проследи по нему граф зависимостей, ага
SK
А - ну то есть цимес только в этом?
SK
Меньше кода для не-бизнесс задач - уже хороший ачивмент
Ну ок, это аргумент. Но сомнительный если честно
SK
Потому что меньше кода за счет *неочевидных* зависимостей на фреймворк (Autowired) - повышение порога вхождения и неопределенность с maintainability.
RM
tradeoff
можно отказаться от этого - и тогда начнуться проблемы в стиле - а что тут использовать, а как этот объект создать, а вот надо его создавать не раньше чем вот этот, а вот этот надо вообще с поддержкой транзакционности и бла бла бла - короч станет тяженько
можно отказаться от этого - и тогда начнуться проблемы в стиле - а что тут использовать, а как этот объект создать, а вот надо его создавать не раньше чем вот этот, а вот этот надо вообще с поддержкой транзакционности и бла бла бла - короч станет тяженько
II
Вообще на сколько я понимаю DI может привнести некоторые упрощения и плюшки которые кому-то могут показаться избыточными, но вообще ноги-то ростут из IoC - https://en.wikipedia.org/wiki/Inversion_of_control
немного упорина о связи DI и IoC
http://www.dotnettricks.com/learn/dependencyinjection/understanding-inversion-of-control-dependency-injection-and-service-locator
немного упорина о связи DI и IoC
http://www.dotnettricks.com/learn/dependencyinjection/understanding-inversion-of-control-dependency-injection-and-service-locator
RM
а еще сверху у тебя есть аспекты, без которых можно забыть про секьюрность и в удобном ввиде.
В конце концов на первом месте должны стоять всегда две вещи - скорость разработки и стабильность получаемого продукта. вроде бы вещи взаимоисключающие, но можно добиться весьма хорошего соотношения используя DI например
В конце концов на первом месте должны стоять всегда две вещи - скорость разработки и стабильность получаемого продукта. вроде бы вещи взаимоисключающие, но можно добиться весьма хорошего соотношения используя DI например
SK
Спорно.
RM
потому что 90% времени ты занят бизнес логикой и только 10% проблем пораждаются DI, а не 50x50
SK
Я в качестве эксперимента отказался в одном домашнем проекте от DI. Резльтат получился интересным
RM
а я вот в домашних проектах вообще DI не использую, лол.
RM
но у меня и классов с гулькин нос
SK
а я вот в домашних проектах вообще DI не использую, лол.
Но топишь за него?))
RM
потмоу что я не стал бы писать ничего серьезного без него) любой мой домашний проект это бесполезный хлам, который не то что не жалко, а я вот даже через месяц уже туда ни за что не полезу, лол.
RM
но так то я и тесты в домашних проектах не пишу, и джавадоки тоже не пишу