Да. Так есть ли у нас терминология чтобы назвать один и второй подход и больше не путаться в ~спорах~ обсуждении?

DI container и руками организованный DI?

Да уже вроде к концу подходит)

Я так думал утром

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

на го до сих пор так делают

у них нет фактически IoC фрейма

даже на больших проектах типа k8s

на го до сих пор так делают

На го много чего делают через ж^W^W по-своему.

DI container и руками организованный DI?

Окей, т.е. Koin, Kodein, Spring, Guice, Dagger - DI Container Создавать классы ручками через конструкторы или сеттеры - DI. Неудобно писать DI Container. Может просто DIC?

дааа дик

дааа дик

?

Guice, Spring и тд это всего лишь DSL для контейнера, на выходе один хрен одинаковая штука выйдет что руками, что со спрингами

Ну а вообще "пробежался по анноташкам и построил граф" — это конкретный DI фреймворк, помогающий организовать DI, собранный руками граф — просто руками организованный DI.

Вот начиная с "пробежался по анноташкам" и возникают проблемы, так как анноташки размазаны по кодовой базе и не проверяются во время компиляции. То есть до запуска приложения граф зависимостей вообще не проверяется, а если в DI фреймворке есть ленивая инициализация зависимостей, то части графа могут и на запуске не провериться. В результате всё собралось, запустилось, вроде работает. Только вот на какой-то хитрой комбинации действий падает на зависимостях.

Guice, Spring и тд это всего лишь DSL для контейнера, на выходе один хрен одинаковая штука выйдет что руками, что со спрингами

О, новый виток. Я пошёл работать всё-таки :D

а со стороны кода уж тем более пофиг кто ему зависимости пропихивать будет

Guice, Spring и тд это всего лишь DSL для контейнера, на выходе один хрен одинаковая штука выйдет что руками, что со спрингами

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

Например через ServiceApi

Вот начиная с "пробежался по анноташкам" и возникают проблемы, так как анноташки размазаны по кодовой базе и не проверяются во время компиляции. То есть до запуска приложения граф зависимостей вообще не проверяется, а если в DI фреймворке есть ленивая инициализация зависимостей, то части графа могут и на запуске не провериться. В результате всё собралось, запустилось, вроде работает. Только вот на какой-то хитрой комбинации действий падает на зависимостях.

А что, споткнуться об ленивую инициализацию в Manual DI невозможно?)

А хуже всего, если не падает, а как-то, из существующего говна и палок оно зависимости смогло собрать, но не те, которые ожидет программист.

А что, споткнуться об ленивую инициализацию в Manual DI невозможно?)

Кстати именно поэтому в Guice есть Development и Production Stage. А в Spring все eager

А что, споткнуться об ленивую инициализацию в Manual DI невозможно?)

Можно, но без пробега по анноташкам (если весь граф кодом описан), проще этот клубок распутать, если что.

Можно, но без пробега по анноташкам (если весь граф кодом описан), проще этот клубок распутать, если что.

Если говорить про практику, то в Guice действительно тяжело. А вот в Spring отличный репортинг. Сразу понятно что где произошло. Ничем не отличается от ручного в этом плане

Ну вот добавилась зависимость в класс, и в случае ручного сбора у тебя упадёт на компиляции, в случае спринга когда то на рантайме

Ну вот добавилась зависимость в класс, и в случае ручного сбора у тебя упадёт на компиляции, в случае спринга когда то на рантайме

На запуске. И что?)

Ну вот добавилась зависимость в класс, и в случае ручного сбора у тебя упадёт на компиляции, в случае спринга когда то на рантайме

так с любым IoC фреймом

но в основном на любом запуске оно упадет в рантайме, на фрейме

если там нет lazy зависимостей

которые внезапно в проде упадут)

На запуске. И что?)

Может тогда на php писать? Нахер сигнатуры, нахер типы

Может тогда на php писать? Нахер сигнатуры, нахер типы

++, у меня те же ассоциации

Может тогда на php писать? Нахер сигнатуры, нахер типы

а вот не надо. на пхп контейнер ты компилируешь отдельно от запуска приложухи

а вот не надо. на пхп контейнер ты компилируешь отдельно от запуска приложухи

какой контейнер

так с любым IoC фреймом

Ну на ведре, используют код-ген (dagger2/toothpick) и в основном падает при компиляции. Хотя имхо, лучше просто тестами покрыть.

На запуске. И что?)

Нету никаких гарантий, что упадёт именно на запуске.

какой контейнер

с зависимостями

У вас везде контейнеры

?

Ну на ведре, используют код-ген (dagger2/toothpick) и в основном падает при компиляции. Хотя имхо, лучше просто тестами покрыть.

Тесты дополняют статическую проверку времени компиляции, но не заменяют её. Чем больше можно проверить компилятором, тем лучше.

ну вообще, если у вас некое подобие микросервисной архитектуры, от фрейм для IoC вам вряд ли нужен будет и достаточно ручками все описывать

а сотню зависимостей можно и ручками описать один раз как @eld0727 и предлагал мне когда-то

Нету никаких гарантий, что упадёт именно на запуске.

Если только что-то не lazy, а если lazy, то тебе и в ручном сборе не мешает упасть. Да что там далеко ходить. Вот вы сделали модуль, который подключаете в runtime, а за зависимостями из вашего Manual DI нужно ходить через ServiceLoader (ну или предложите compile-time safe true fp way). Вот и все, все на рантайме, может упасть, как жить)

Ладно, всем удачи в этом чатике. Работа стоит.

а сотню зависимостей можно и ручками описать один раз как @eld0727 и предлагал мне когда-то

я думаю можно 1000 описать без проблем

Они не появляются все разом

Тесты дополняют статическую проверку времени компиляции, но не заменяют её. Чем больше можно проверить компилятором, тем лучше.

Блин, у меня и так компиляция по 1.5 минуты и переключение бранчей по 30 сек. Лучше уж на кложе писать и тестами интеграционными покрывать.

я думаю можно 1000 описать без проблем

да в целом, а если нельзя разнести их на отдельные модули то тут уже проблема с coupling

Если только что-то не lazy, а если lazy, то тебе и в ручном сборе не мешает упасть. Да что там далеко ходить. Вот вы сделали модуль, который подключаете в runtime, а за зависимостями из вашего Manual DI нужно ходить через ServiceLoader (ну или предложите compile-time safe true fp way). Вот и все, все на рантайме, может упасть, как жить)

У нас, в JVM мире, даже загрузка классов происходит на рантайме, ClassLoader. И ничего, живем.

в общем я честно пытался koin/kodein заюзать, но как-то расстроился сильно

Если только что-то не lazy, а если lazy, то тебе и в ручном сборе не мешает упасть. Да что там далеко ходить. Вот вы сделали модуль, который подключаете в runtime, а за зависимостями из вашего Manual DI нужно ходить через ServiceLoader (ну или предложите compile-time safe true fp way). Вот и все, все на рантайме, может упасть, как жить)

> Модуль, который подключается в рантайме. А зачем?

кровью интерпрайза пахнет

кровью интерпрайза пахнет

У тебя есть скомпиленный jar, который строит тебе из набора adoc файлов сайтик. И ты хочешь к нему подключить плагин, который когда видит [youtube=fsdfsd] вставляет на этом месте iframe. У тебя есть два пути - заставить всех пользователей ставить jdk и запускать idea, править код чтобы подключить плагин, или загружать зависимости на рантайме. Какой выберешь? И вот сейчас всем хейтерам DI Container предлагаю написать компайл-тайм сейф код для этой задачи)

я не хейтер)) я сторонник YAGNI/KISS

я не хейтер)) я сторонник YAGNI/KISS

Ну ты не хейтер, ты и не пиши)

?

У тебя есть скомпиленный jar, который строит тебе из набора adoc файлов сайтик. И ты хочешь к нему подключить плагин, который когда видит [youtube=fsdfsd] вставляет на этом месте iframe. У тебя есть два пути - заставить всех пользователей ставить jdk и запускать idea, править код чтобы подключить плагин, или загружать зависимости на рантайме. Какой выберешь? И вот сейчас всем хейтерам DI Container предлагаю написать компайл-тайм сейф код для этой задачи)

Задача в том, чтобы скачивать и подключать jar только при необходимости?

Задача в том, чтобы скачивать и подключать jar только при необходимости?

Задача в том чтобы реализовать плагинную систему на Manual DI, но так чтобы под ваши высокие стандарты чистоты и компайл-тайм сейфити подходило.

Задача в том чтобы реализовать плагинную систему на Manual DI, но так чтобы под ваши высокие стандарты чистоты и компайл-тайм сейфити подходило.

Нужно что-то около-SPI-ное, когда класс забирается по имени, но реализует определённый интерфейс, поэтому дальше всё снова безопасно.

Более того, можно подключить как compileOnly и даже написать new, просто оградить этот кусочек кода, чтобы не вызвать его, когда класса нет.

Нужно что-то около-SPI-ное, когда класс забирается по имени, но реализует определённый интерфейс, поэтому дальше всё снова безопасно.

Ну естесвенно. Так и DI Container. Он построил тебе контекст, можно выдохнуть - дальше все безопасно)

Ну естесвенно. Так и DI Container. Он построил тебе контекст, можно выдохнуть - дальше все безопасно)

Разница в масштабах. «загружу один класс по имени» или «пусть 1000 объектов там сами как-нибудь»

Разница в масштабах. «загружу один класс по имени» или «пусть 1000 объектов там сами как-нибудь»

Так я сделаю задачу более реалистичной: У тебя класс подтянутый по SPI имеет конструктор и хочет от тебя зависимости. Ну в простейшем случае ObjectMapper. Но ты понимаешь - это интерфейс, ты не знаешь какие у тебя будут плагины, но плагины хотят любие классы которые у тебя в core.

А что такое ObjectMapper?

А что такое ObjectMapper?

Да любой класс который в core

Чет сложно (я под андроид пишу). ObjectMapper это типа класс, который мапит одни VO в др VO (value-object)?

Я даже подскажу тебе первый шаг. У тебя есть вот таких два класса: interface Plugin interface PluginProvider { fun get(): KClass<out Plugin> } и ты наверное в плагине сделаешь как-то так: cat resources/META-INF/services/PluginProvider my.pacakge.CoolPlugin

Чет сложно (я под андроид пишу). ObjectMapper это типа класс, который мапит одни VO в др VO (value-object)?

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

И при этом он сам зависимость, для тебя

Стандартная задача

ERROR: S client not available

Чет сложно (я под андроид пишу). ObjectMapper это типа класс, который мапит одни VO в др VO (value-object)?

Это Jackson

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

А ну лан. У меня были мысли, конкретно про маперы, что их нужно заменять static-методами.

Так я сделаю задачу более реалистичной: У тебя класс подтянутый по SPI имеет конструктор и хочет от тебя зависимости. Ну в простейшем случае ObjectMapper. Но ты понимаешь - это интерфейс, ты не знаешь какие у тебя будут плагины, но плагины хотят любие классы которые у тебя в core.

dependency rejection

dependency rejection

не понял

Превратить объект в пачку функций. Без зависимостей. Передавать ObjectMapper в каждый метод, в котором он может понадобиться.

Котлин коммунити потихоньку превращется в ДИ ИоК чат)

Превратить объект в пачку функций. Без зависимостей. Передавать ObjectMapper в каждый метод, в котором он может понадобиться.

Т.е. плагин будет напряму дергать (static?!) функции

самое забавное, что раньше когда я участвовал в DI срачах - они были про ServiceLocator vs DependencyInjectionContainer

Т.е. плагин будет напряму дергать (static?!) функции

Не-не. В интерфейсе, который реализует плагин, методы должны принимать этот ObjectMapper.

Потому что мы-то внутри себя вполне можем дропнуть Jackson, а плагин ничего об этом не будет знать — а так это прописано явно.

Не-не. В интерфейсе, который реализует плагин, методы должны принимать этот ObjectMapper.

т.е. интерфейс плагина должен знать про все плагины?

т.е. интерфейс плагина должен знать про все плагины?

Интерфейс плагина должен описывать функции без partial application, т. е. без собственных зависимостей.

Потому что непонятно, откуда зависимостям браться.

Интерфейс плагина должен описывать функции без partial application, т. е. без собственных зависимостей.

У разных плагинов разные зависимости, как ты в Core Plugin интерфейсе опишешь все возможные зависимости?

У разных плагинов разные зависимости, как ты в Core Plugin интерфейсе опишешь все возможные зависимости?

Как ты их предоставишь?

Так я тебе и спрашиваю, как без этого мерзкого рефлекшена решить вот такую задачку

Рефлекшеном - изи, взял провайдер, получил KClass, вызвал конструктор в который из DI контейнера напихал зависимостей

Рефлекшеном - изи, взял провайдер, получил KClass, вызвал конструктор в который из DI контейнера напихал зависимостей

напихал зависимостей — откуда?

напихал зависимостей — откуда?

> из DI контейнера

Это я тебе говорю как в реальном мире решить задачу

Вот начиная с "пробежался по анноташкам" и возникают проблемы, так как анноташки размазаны по кодовой базе и не проверяются во время компиляции. То есть до запуска приложения граф зависимостей вообще не проверяется, а если в DI фреймворке есть ленивая инициализация зависимостей, то части графа могут и на запуске не провериться. В результате всё собралось, запустилось, вроде работает. Только вот на какой-то хитрой комбинации действий падает на зависимостях.

анноташки как какашки по проекту внедрены

> из DI контейнера

ну вот не знаю я ничего про ObjectMapper, у меня нет Jackson или он настроен не так, как нужно плагину

И тут рефлекшен, DI контейнер, все по худшим стандартам

Так я тебе и спрашиваю, как без этого мерзкого рефлекшена решить вот такую задачку

Руками собрал граф и всё

Руками собрал граф и всё

не совсем, читай выше)

Руками собрал граф и всё

А как граф передать в динамический модуль? Это ж что ж, servise loader предлагаешь делать? Нужно же сделать DI!

немного не в тему, но вопрос - как вы держите swagger ui, один на все проекты, или в каждом проекте свой?

А как граф передать в динамический модуль? Это ж что ж, servise loader предлагаешь делать? Нужно же сделать DI!

так, еще раз можно задачку: у нас есть плагин, так? Который мы подключаем динамически, так?

я просто андроид-разработчик, мне твои сокращения и термины не очень понятны

Да, плагин реализует интерфейс Plugin (который мы сами написали), core модуль на рантайме загружает набор plugin модулей с реализацией интерфейса Plugin.

Так я сделаю задачу более реалистичной: У тебя класс подтянутый по SPI имеет конструктор и хочет от тебя зависимости. Ну в простейшем случае ObjectMapper. Но ты понимаешь - это интерфейс, ты не знаешь какие у тебя будут плагины, но плагины хотят любие классы которые у тебя в core.

Я правильно понял, что вы предлагаете всё core API предоставить плагинам в распоряжение? То есть любой плагин может любой сервис core приложения дёргать как ему вздумается?

Я правильно понял, что вы предлагаете всё core API предоставить плагинам в распоряжение? То есть любой плагин может любой сервис core приложения дёргать как ему вздумается?

Да, такой вот не очень хороший подход, но plugin может хотеть любую часть core