НС>Я просто напомню, что разговор начался с утверждения, что рассчет графа хависимостей это главная функция DI контейнера.

Да, тот самый "service locator" (он же "поиск зависимостей", он же "построение графа"). Честно говоря, не вижу, в чем состоит несогласие.

НС>А я не понимаю, как можно в обсуждении неправильности service locator и правильности DI игнорировать заявления о неправильности service locator.

Вы меня с кем-то спутали. Я не сторонник называть что-то правильным или неправильным. У каждого решения есть свои плюсы и минусы. Лично мне в DI (контейнерах) видится больше минусов, чем плюсов — я уже объяснял, что не вижу смысла код создания зависимостей на Java выносить в отдельные файлы (XML) и наворачивать дополнительные уровни абстракции для того, чтобы потом в итоге все равно создать Java объекты, все из того же реестра.

НС> Это можно сказать про любую более менее сложную технологию.

Кстати да, сложность — это не достоинство. Это недостаток. Сложность ограничивает нашу скорость движения вперед. И если эту сложность не получается хорошо скрыть за правильно подобраной абстрацией (leaky abstraction — беда любого программиста, включая очень себе сеньоров), то именно сложность и является основной проблемой.

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

НС>>А я не понимаю, как можно в обсуждении неправильности service locator и правильности DI игнорировать заявления о неправильности service locator.
SD>Вы меня с кем-то спутали.

Это не ты написал?

НС>Разница тут будет только в случае вызова метода Resolve, что тут все заклеймили позором как антипаттерн..
Да мало ли что где клеймят.

SD>я уже объяснял, что не вижу смысла код создания зависимостей на Java выносить в отдельные файлы (XML)

А я уже отвечал, что в 2021 году почти никто уже не видит смысла в этом и в свежих контейнерах такой фичи просто нет. Так какой смысл постоянно переводить разговор на это дерьмо мамонта?

НС>> Это можно сказать про любую более менее сложную технологию.
SD>Кстати да, сложность — это не достоинство. Это недостаток.

Конечно. Но так редко бывает, что у сложных проблем есть простые решения.

НС>Это не ты написал?
НС>

НС>>Разница тут будет только в случае вызова метода Resolve, что тут все заклеймили позором как антипаттерн..
НС>Да мало ли что где клеймят.

Я service locator позором не клеймил, ибо с какого угла ни посмотри, но некий способ развернуть имя в объект в любом случае должен быть.

НС>А я уже отвечал, что в 2021 году почти никто уже не видит смысла в этом и в свежих контейнерах такой фичи просто нет. Так какой смысл постоянно переводить разговор на это дерьмо мамонта?

И как же делают в 2021 году?
А код, который был до 2021, тоже уже весь переписали?

НС>Конечно. Но так редко бывает, что у сложных проблем есть простые решения.

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

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

НС>>

НС>>>Разница тут будет только в случае вызова метода Resolve, что тут все заклеймили позором как антипаттерн..
НС>>Да мало ли что где клеймят.

SD>Я service locator позором не клеймил

Так и процитированный ответ был не тебе.

НС>>А я уже отвечал, что в 2021 году почти никто уже не видит смысла в этом и в свежих контейнерах такой фичи просто нет. Так какой смысл постоянно переводить разговор на это дерьмо мамонта?
SD>И как же делают в 2021 году?

В коде.

SD>А код, который был до 2021, тоже уже весь переписали?

Без понятия. Почему ты это хочешь обсудить?