Какая то надуманная херня

Дробишь проекты на модули, которые зависят от других модулей

а что если нужен один и тот же инстанс в разных ветках? давайте будем прокидывать от общего родителя! класс)

А что если нужно несколько реализаций одного интерфейса? Давайте придумаем Qualifier! Класс!

потом это все поддерживать

Особенно когда несколько человек это будут в параллель редактировать, очень веселое занятие

А в чем проблема то?

я смотрю ты фанат прокидывать 50+ параметров через конструкторы на глубину тех 50 вызовов?) мое уважение, но это кхм, говнокод)

я смотрю ты фанат прокидывать 50+ параметров через конструкторы на глубину тех 50 вызовов?) мое уважение, но это кхм, говнокод)

каких 50 вызовов

такс, давайте теперь расскажите как разруливаете циклические зависимости через конструкторы

у вас помоему проблема с архитектурой

я смотрю ты фанат прокидывать 50+ параметров через конструкторы на глубину тех 50 вызовов?) мое уважение, но это кхм, говнокод)

иметь 50 зависимостей — это говнокод и нарушение SRP

такс, давайте теперь расскажите как разруливаете циклические зависимости через конструкторы

циклические зависимости — говнокод

такс, давайте теперь расскажите как разруливаете циклические зависимости через конструкторы

азазаз циклические зависимости

Особенно когда несколько человек это будут в параллель редактировать, очень веселое занятие

во во

А что если нужно несколько реализаций одного интерфейса? Давайте придумаем Qualifier! Класс!

+

циклические зависимости — говнокод

ну не скажите

иметь 50 зависимостей — это говнокод и нарушение SRP

ну сам бин будет иметь 5 зависимостей, а остальные будут прокинуты дальше

я смотрю ты фанат прокидывать 50+ параметров через конструкторы на глубину тех 50 вызовов?) мое уважение, но это кхм, говнокод)

Переходить на личности прям ок в дискуссии, претендующей на объективность

Переходить на личности прям ок в дискуссии, претендующей на объективность

я не переходил

ну сам бин будет иметь 5 зависимостей, а остальные будут прокинуты дальше

Куда «дальше»? Всё должно собираться точкой входа.

ну лан, опять пошли бессмысленные споры в интернете, ничего полезного

писос

Куда «дальше»? Всё должно собираться точкой входа.

на 100500 строк

человек просто не понимает о чем ему говорят

куда то прокидывать собирается

человек просто не понимает о чем ему говорят

и это не переход на личности

человек просто не понимает о чем ему говорят

как будто это редкость)

ну лан, опять пошли бессмысленные споры в интернете, ничего полезного

А как вы хотите чтобы я общался после подобных высказываний

А как вы хотите чтобы я общался после подобных высказываний

я тебя оскорбил? вах

ну лан, опять пошли бессмысленные споры в интернете, ничего полезного

«всё равно каждый останется при своём мнении, соскочу-ка я»

я тебя оскорбил? вах

нет, я тоже никого не оскорблял

«всё равно каждый останется при своём мнении, соскочу-ка я»

а смысл дальше спорить если ничего не докажешь?

а смысл дальше спорить если ничего не докажешь?

Можно честно признать, что не понимаешь, о чём речь, и никогда так не пробовал.

Можно честно признать, что не понимаешь, о чём речь, и никогда так не пробовал.

я понимаю и пробовал

такс, давайте теперь расскажите как разруливаете циклические зависимости через конструкторы

1. Циклические зависимости - это обычно плохо. 2. Если сильно надо - можно разрулить их, сделав ленивую инициализацию одной из них.

1. Циклические зависимости - это обычно плохо. 2. Если сильно надо - можно разрулить их, сделав ленивую инициализацию одной из них.

2 - этим большинство контейнеров и занимаются из коробки

В спрнге вообще можно самого себя в себя заинжектить

так в итоге DI нужен или нет и какие аргументы за, а какие против?)

2 - этим большинство контейнеров и занимаются из коробки

...тем самым скрывая проблемные места, которые необходимо рефакторить.

так в итоге DI нужен или нет и какие аргументы за, а какие против?)

Если к у тебя больше 30 зависимостей и двух человек в проекте, то мое мнение что нужно. Иначе погрязнете в шаблонном коде.

так в итоге DI нужен или нет и какие аргументы за, а какие против?)

так с этого всё и началось

Я вам сейчас открою тайну, создание через конструктор - и есть DI

так в итоге DI нужен или нет и какие аргументы за, а какие против?)

имха, DI можно тока когда ты и без него можешь сделать нормально и DI по каким то причинам удобнее

Я вам сейчас открою тайну, создание через конструктор - и есть DI

Ура

Если к у тебя больше 30 зависимостей и двух человек в проекте, то мое мнение что нужно. Иначе погрязнете в шаблонном коде.

+

Я вам сейчас открою тайну, создание через конструктор - и есть DI

Это IoC)

кажется, срач DI == контейнер vs DI != контейнер ну совсем не имеет смысла.

срачи ваще не имеют смысла =)

2 - этим большинство контейнеров и занимаются из коробки

Я в курсе, чем занимаются DI контейнеры. Мои претензии, которые вы назвали бредом, к тому, что делают они это не прозрачно для конечного пользователя. Вообще, DI в том виде, в котором существует - зло. Главные вопросы, которые лично меня интересуют: 1. Есть ли production ready альтернативы? 2. Можно ли реализовать добрый DI (прозрачный)? Говоря проще, является ли DI неизбежным злом для больших проектов, или есть варианты лучше?

срачи ваще не имеют смысла =)

не соглашусь)

не соглашусь)

колесо сансары дало оборот

Я в курсе, чем занимаются DI контейнеры. Мои претензии, которые вы назвали бредом, к тому, что делают они это не прозрачно для конечного пользователя. Вообще, DI в том виде, в котором существует - зло. Главные вопросы, которые лично меня интересуют: 1. Есть ли production ready альтернативы? 2. Можно ли реализовать добрый DI (прозрачный)? Говоря проще, является ли DI неизбежным злом для больших проектов, или есть варианты лучше?

что значит не прозрачно? всегда можно узнать что заинжектится

Я в курсе, чем занимаются DI контейнеры. Мои претензии, которые вы назвали бредом, к тому, что делают они это не прозрачно для конечного пользователя. Вообще, DI в том виде, в котором существует - зло. Главные вопросы, которые лично меня интересуют: 1. Есть ли production ready альтернативы? 2. Можно ли реализовать добрый DI (прозрачный)? Говоря проще, является ли DI неизбежным злом для больших проектов, или есть варианты лучше?

1 - бр, остановите землю, я сойду

что значит не прозрачно? всегда можно узнать что заинжектится

ну почти

я смотрю ты фанат прокидывать 50+ параметров через конструкторы на глубину тех 50 вызовов?) мое уважение, но это кхм, говнокод)

Говнокод здесь в том, что ты передаешь параметры для создания зависимости в класс вместо того чтобы передать саму зависимость

ну почти

Ну вот это самое "ну почти", оно и есть не прозрачность.

Давайте вы будете исходить из изначального предназначения и причин создания такого понятия, как DI:) а то пока что всё, что я читаю, сводится к тому, у кого больше говно-/бесполезнокода

Ну вот это самое "ну почти", оно и есть не прозрачность.

давай конкретику

А конструктивная критика будет? Или так и будет голову в песок и абстрактное: "вы не умеете готовить"?

Да вы же сами только что её и дали, что не всегда можно узнать, что конкретно заинжектится.

Опять же, а какие альтернативы с точки соблюдения инверсии зависимостей и принципа сокрытия реализации?

ну если не контроллируешь контекст - не узнаешь. если контроллируешь - то знаешь и даже больше - уверен

Опять же, а какие альтернативы с точки соблюдения инверсии зависимостей и принципа сокрытия реализации?

Не использовать инверсию?

Не использовать инверсию?

Нарушаете, товарищ?:)

Нарушаете, товарищ?:)

?

Не использовать инверсию?

Принцип сокрытия реализации - это использование интерфейсов вместо конкретных реализаций

Принцип сокрытия реализации - это использование интерфейсов вместо конкретных реализаций

И неиспользование new, требующего использовать конкретную реализацию, а не интерфейс

ERROR: S client not available

И неиспользование new, требующего использовать конкретную реализацию, а не интерфейс

это делается только в точке входа, которая за это и отвечает

это делается только в точке входа, которая за это и отвечает

Которой обычно является DI, потому что иначе принцип нарушается

и приходим к тому что DI нужен

Которой обычно является DI, потому что иначе принцип нарушается

стап ит

кек

С точки зрения занудства, DI штука необходимая

С чего вы взяли что это что то нарушает вообще

С точки зрения занудства, DI штука необходимая

Нет, говорю как главный зануда.

Нет, говорю как главный зануда.

Поддерживаю

С точки зрения реалий, нефиг заморачиваться, если оно не поможет

di нужен чтобы расчесать вермешель в нормальную структуру

возложив ответственность на ioc

Опыт показывает, что какого-нибудь сервис-локатора зачастую хватает с головой для организации зависимостей

ну да

возложив ответственность на ioc

IoC — это концепцая, на неё невозможно возлагать ответственность

но с сервис локатором - вермешель может быть вообще лютая

Опыт показывает, что какого-нибудь сервис-локатора зачастую хватает с головой для организации зависимостей

Во, хоть какая-то названная альтернатива

di нужен чтобы расчесать вермешель в нормальную структуру

Императивную-ооп вермишель ?

Императивную-ооп вермишель ?

так императивную или ООП?

TL;DR

Императивную-ооп вермишель ?

сложно

Во, хоть какая-то названная альтернатива

То есть то что мы говорим это не альтернатива?

ну работать с кодом, когда етсь DI куда удобнее - это факт

быстро привыкаешь и обратно не хочешь

так императивную или ООП?

одно не исключает другое shrug

Вы определитесь, какая конечная цель спора - точки соприкосновения

То есть то что мы говорим это не альтернатива?

С точки зрения назначения DI - нет, вы говорите, что он не нужен:)

<kt

так императивную или ООП?

"ООП" в Java/EE представление

Вы определитесь, какая конечная цель спора - точки соприкосновения

Именно

одно не исключает другое shrug

ИМХО, исключает

"ООП" в Java/EE представление

это называется «процедурщина»