в котлине нет new

но он ведь в java, то что нет new не означает что он без него обходится внутри

но он ведь в java, то что нет new не означает что он без него обходится внутри

Вобще, насколько я помню, создание объекта через ObjectClass(…) - самое что ни на есть new, нет?

Откуда у вас такая интерпритация термина DI вообще?

Откуда у вас такая интерпритация термина DI вообще?

Какая

Вы контейнеры называете DI

вот это строчка Server(kodein, applications).start() превращается в byte code IR (new Server((Kodein)kodein, applications, 0, 4, (DefaultConstructorMarker)null)).start(); ну типа джавовский код

Вы контейнеры называете DI

Так DI это когда зависимости внедряются извне, это не передача параметров(зависимостей) в конструктор, а имеено внендрение фреймворком

но он ведь в java, то что нет new не означает что он без него обходится внутри

это был небольшой наброс

Так DI это когда зависимости внедряются извне, это не передача параметров(зависимостей) в конструктор, а имеено внендрение фреймворком

nope

Так DI это когда зависимости внедряются извне, это не передача параметров(зависимостей) в конструктор, а имеено внендрение фреймворком

Википедия согласна. Если почитать https://en.wikipedia.org/wiki/Dependency_injection и https://en.wikipedia.org/wiki/Inversion_of_control

первая часть правда

вторая нет

Ну у меня авторитетный источник

вторая уже про IoC

Написано что Dependency Injection это подвид IoC

А вот Dependency Inversion Principle это когда ты ручками через конструктор или сеттер или прямо в поле, не важно. главное чтобы интерфейс https://en.wikipedia.org/wiki/Dependency_inversion_principle

Ты не понял, о чем говорит Quantum. Когда мы говорим об инициализации через конструктор мы не говорим об class A(val Bparams, val Cparams){ val c = C(Cparams) val b = B(Bparams) } как бы ты мог подумать. Мы говорим о class A(val b: B, val c: C) fun main(...){ val c = C(cParams) val b = B(bParams) val A = A(b, c) } Никакого нарушения солид, как видишь, нет. И для того чтобы самому руководить зависимостями DI-контейнер не нужен, достаточно фабрики

Ruslan То есть вот этот код снизу это не DI?

Это DIP

Из вашей же ссылки > dependency injection is a technique whereby one object (or static method) supplies the dependencies of another object.

main предоставил объекту A инстансы объектов B и C?

Из вашей же ссылки > dependency injection is a technique whereby one object (or static method) supplies the dependencies of another object.

Все верно, читаем дальше объяснение и видим: > Dependency injection is one form of the broader technique of inversion of control. As with other forms of inversion of control, dependency injection supports the dependency inversion principle. И дальше > The client delegates the responsibility of providing its dependencies to external code (the injector).

Жить без DIP нельзя, а без IoC(DI) можно. Главное отказавшись от готовых DI, наевшись ручного constructor injection не начать писать свой маленький DI.

> Жить без DIP нельзя А можно фактические причины почему?

Все верно, читаем дальше объяснение и видим: > Dependency injection is one form of the broader technique of inversion of control. As with other forms of inversion of control, dependency injection supports the dependency inversion principle. И дальше > The client delegates the responsibility of providing its dependencies to external code (the injector).

И это опять же про этот код с main'ом

Нигде нет слова, что это должен делать контейнер

Егор Бугаенко публиковал статью о DI без контейнера, и тот код, который он называет The right way без слез читать невозможно - жуткая вермишель с несколькими уровнями вложенности. https://www.yegor256.com/2014/10/03/di-containers-are-evil.html Гоферам наверное нравится явно писать такие портянки руками, но глядя на код, хочется иметь возможность описать это конфигурацией.

> Жить без DIP нельзя А можно фактические причины почему?

Задавай вопрос тому кто изначально стейтмент видвинул, я не хочу защищать таки аксиомы для себя. Фаулер и Роберт Мартин постарались в своих книгах этот вопрос закрыть

Егор Бугаенко публиковал статью о DI без контейнера, и тот код, который он называет The right way без слез читать невозможно - жуткая вермишель с несколькими уровнями вложенности. https://www.yegor256.com/2014/10/03/di-containers-are-evil.html Гоферам наверное нравится явно писать такие портянки руками, но глядя на код, хочется иметь возможность описать это конфигурацией.

Ой, ну вот давай-те без Егора

Егор Бугаенко публиковал статью о DI без контейнера, и тот код, который он называет The right way без слез читать невозможно - жуткая вермишель с несколькими уровнями вложенности. https://www.yegor256.com/2014/10/03/di-containers-are-evil.html Гоферам наверное нравится явно писать такие портянки руками, но глядя на код, хочется иметь возможность описать это конфигурацией.

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

Нигде нет слова, что это должен делать контейнер

Вроде достаточно очевидно про container (injector) написано: > The client delegates the responsibility of providing its dependencies to external code (the injector). > The injector introduces the services into the client. Often, it also constructs the client. An injector may connect together a very complex object graph by treating an object like a client and later as a service for another client. The injector may actually be many objects working together but may not be the client. The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main.

Вроде достаточно очевидно про container (injector) написано: > The client delegates the responsibility of providing its dependencies to external code (the injector). > The injector introduces the services into the client. Often, it also constructs the client. An injector may connect together a very complex object graph by treating an object like a client and later as a service for another client. The injector may actually be many objects working together but may not be the client. The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main.

Где тут сказано что это ДОЛЖЕН быть контейнер

Вроде достаточно очевидно про container (injector) написано: > The client delegates the responsibility of providing its dependencies to external code (the injector). > The injector introduces the services into the client. Often, it also constructs the client. An injector may connect together a very complex object graph by treating an object like a client and later as a service for another client. The injector may actually be many objects working together but may not be the client. The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main.

Дык эцсамое, вышеприведенная main тоже по сути injector.

Где тут сказано что это ДОЛЖЕН быть контейнер

Смотри, в статье говорится что DI это вид IoC, так?

Дык эцсамое, вышеприведенная main тоже по сути injector.

ну да

Дык эцсамое, вышеприведенная main тоже по сути injector.

main это клиентский код, идея injector'а что это что-то внешнее что тебе провайдит зависимости

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

main это клиентский код, идея injector'а что это что-то внешнее что тебе провайдит зависимости

окей, если я эти три строчки вынесу из main в класс AFactory, это будет DIP, DI или IoC?

main это клиентский код, идея injector'а что это что-то внешнее что тебе провайдит зависимости

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

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

+

Вот так мы провели рабочий вторник в устаканивании терменологии

Строго говоря, main вообще обычно мало полезной нагрузки в софте имеет, вся интересная с точки зрения бизнеса часть оттуда вынесена. Сама точка входа логически обычно относится к фреймворку, а написан он тобой или кем-то другим — дело третье.

окей, если я эти три строчки вынесу из main в класс AFactory, это будет DIP, DI или IoC?

DIP будет все где ты разделяешь создание и использование зависимости. DI(IoC) это все где ты не сам передаешь зависимости, а отдаешь это на откуп фреймворку, который уже собирает твой граф для тебя. Поэтому если ты вынес в код куда-то, а потом собрал граф ручками это конечно DIP, но не DI.

Задавай вопрос тому кто изначально стейтмент видвинул, я не хочу защищать таки аксиомы для себя. Фаулер и Роберт Мартин постарались в своих книгах этот вопрос закрыть

Те сам то ты не читаешь что DIP нужен?

При использовании ктора того же мэин обычно собирает и запускает сервер и дожидается его возврата. В ведре мэина вообще нету, там всё делает зигота и в конце концов просто пинаются определённые программистом делегаты. В JavaFX мэин есть, но его единственная задача — передать управление фреймворку. Да в любой системе с ивент лупом так будет. IoC — это подход, который реализовать может кто угодно, в том числе единственный на проекте программист, который вообще внешние библиотеки не подключает. Управление от этого выворачиваться не перестаёт :)

Можно вернуться в статью про IoC в которой написано что IoC это фреймворк в который ты подключаешься, а чуть ниже что Dependency Injection это подвид IoC; In software engineering, inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework. Dependency injection is a specific type of IoC.

DIP будет все где ты разделяешь создание и использование зависимости. DI(IoC) это все где ты не сам передаешь зависимости, а отдаешь это на откуп фреймворку, который уже собирает твой граф для тебя. Поэтому если ты вынес в код куда-то, а потом собрал граф ручками это конечно DIP, но не DI.

т.е. kodein - DIP он же сам не собирает граф, все руками нужно

т.е. kodein - DIP он же сам не собирает граф, все руками нужно

DIP — это абстрактный принцип

т.е. kodein - DIP он же сам не собирает граф, все руками нужно

Это Service Locator

Можно вернуться в статью про IoC в которой написано что IoC это фреймворк в который ты подключаешься, а чуть ниже что Dependency Injection это подвид IoC; In software engineering, inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework. Dependency injection is a specific type of IoC.

Дык если фреймворк — это одна функция и она написана тем же, кто и остальной код написал, IoC перестаёт быть IoC?

Это Service Locator

это зависит от того как юзатть)

это зависит от того как юзатть)

А как можно юзать кодеин не как сервис локатор? Хочу пример.

А как можно юзать кодеин не как сервис локатор? Хочу пример.

только энтрипоинты поднимать им и все

Я почему-то всегда был уверен, что кодеин — это просто Map на стероидах и основной принцип работы — с одной стороны всё в него свалить, с другой — вычитать по нужде.

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

Дык если фреймворк — это одна функция и она написана тем же, кто и остальной код написал, IoC перестаёт быть IoC?

Смотрите, во-первых я не хочу всем доказать что это так, @Enleur показал мне например сейчас что я вчера был неправ про IoC и DI, там где я говорил IoC я думал про DIP. И в жизни я тоже не говорю DIP, IoC. DI и DI, все понятно. Теперь к вопросу о функции. Как я вижу от того что ты перенес код из main в фунцию у тебя принципиально ничего не поменялось. Тут дело в том кто создает instance класса. Если ты функции передал что у тебя есть класс A и B: class A(b: B) class B(c: C, om: ObjectMapper) И она создала инстансы A, B, C, ObjectMapper - то это конечно IoC, а если ты сам в этой функции сделал val c = C() val b = B(c, ...) ... то нет.

Кстати сделать модули в рантайме без какого-то вида IoC у вас не получится.

Смотрите, во-первых я не хочу всем доказать что это так, @Enleur показал мне например сейчас что я вчера был неправ про IoC и DI, там где я говорил IoC я думал про DIP. И в жизни я тоже не говорю DIP, IoC. DI и DI, все понятно. Теперь к вопросу о функции. Как я вижу от того что ты перенес код из main в фунцию у тебя принципиально ничего не поменялось. Тут дело в том кто создает instance класса. Если ты функции передал что у тебя есть класс A и B: class A(b: B) class B(c: C, om: ObjectMapper) И она создала инстансы A, B, C, ObjectMapper - то это конечно IoC, а если ты сам в этой функции сделал val c = C() val b = B(c, ...) ... то нет.

Вот этот ``` om: ObjectMapper ``` вполне может быть "крадёт" параметры у методов класса B.

Привет, есть проект со спрингом, котлином и гибернейтом. Энтити - котлиновские дата классы с иммутабельными свойствами(val). Слышал, что хорошая практика изменять объекты через copy, могут ли быть какие-то проблемы в этом случае пр. работе с гиьернейтом?

Смотрите, во-первых я не хочу всем доказать что это так, @Enleur показал мне например сейчас что я вчера был неправ про IoC и DI, там где я говорил IoC я думал про DIP. И в жизни я тоже не говорю DIP, IoC. DI и DI, все понятно. Теперь к вопросу о функции. Как я вижу от того что ты перенес код из main в фунцию у тебя принципиально ничего не поменялось. Тут дело в том кто создает instance класса. Если ты функции передал что у тебя есть класс A и B: class A(b: B) class B(c: C, om: ObjectMapper) И она создала инстансы A, B, C, ObjectMapper - то это конечно IoC, а если ты сам в этой функции сделал val c = C() val b = B(c, ...) ... то нет.

Касательно "сам в функции создал экземпляры классов" — это, ясное дело, не DI, не IoC, не DIP, потому что функция знает о конкретных реализациях того, что она использует. Я всего лишь о таком: class A(b: B) { fun doUsefulStuff() { ... } } interface B class BImpl(c: C): B class C fun main() { val c = C() val b = BImpl(c) val a = A(b) a.doUsefulStuff() } Вот в этом примере main — это injector, внешний по отношению к бизнес-логике фреймворк; вышеперечисленные классы и метод doUsefulStuff — это клиентский код, которому фиолетово, где какие реализации зависимостей есть, и в этом всём нету никакого контейнера.

например получил данные из бд, через copy изменил и сохранил через save

напрягает, что гибернейт использует proxy объектов

Касательно "сам в функции создал экземпляры классов" — это, ясное дело, не DI, не IoC, не DIP, потому что функция знает о конкретных реализациях того, что она использует. Я всего лишь о таком: class A(b: B) { fun doUsefulStuff() { ... } } interface B class BImpl(c: C): B class C fun main() { val c = C() val b = BImpl(c) val a = A(b) a.doUsefulStuff() } Вот в этом примере main — это injector, внешний по отношению к бизнес-логике фреймворк; вышеперечисленные классы и метод doUsefulStuff — это клиентский код, которому фиолетово, где какие реализации зависимостей есть, и в этом всём нету никакого контейнера.

Это не injector, ты сам создаешь инстансы. Ты не можешь взять этот injector и переопределить там класс который реализует B

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

Это не injector, ты сам создаешь инстансы. Ты не можешь взять этот injector и переопределить там класс который реализует B

А где такие требования к понятию injector описаны?

Перечитываю статью по DI и не вижу ничего такого.

Перечитываю статью по DI и не вижу ничего такого.

Согласен, там не сказано жестко что injector это фреймворк: The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main. На подводить под одну черту main где я ручками собрал граф, и фреймворк который сам собрал тебе граф странно.

Итак, насчёт IoC: IoC - принцип, при котором часть программы (объект или статический метод) получает куски control flow извне. Это не обязательно DI. Пример IoC не являющегося DI - экстеншн метод map для Iterable в Kotlin.

ERROR: S client not available

Привет, есть проект со спрингом, котлином и гибернейтом. Энтити - котлиновские дата классы с иммутабельными свойствами(val). Слышал, что хорошая практика изменять объекты через copy, могут ли быть какие-то проблемы в этом случае пр. работе с гиьернейтом?

скорее всего будут, так как хибер построен на гетерах/сетерах

Согласен, там не сказано жестко что injector это фреймворк: The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main. На подводить под одну черту main где я ручками собрал граф, и фреймворк который сам собрал тебе граф странно.

main прям последним словом стоит ?

Согласен, там не сказано жестко что injector это фреймворк: The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main. На подводить под одну черту main где я ручками собрал граф, и фреймворк который сам собрал тебе граф странно.

А я не вижу проблем. Для самой сути DI не особо важно, КАК собирается граф, важно, что всем клиентам извне поставляются их зависимости. Ну и как верно выше заметили, IoC вообще абстрактнее этого всего.

Привет, есть проект со спрингом, котлином и гибернейтом. Энтити - котлиновские дата классы с иммутабельными свойствами(val). Слышал, что хорошая практика изменять объекты через copy, могут ли быть какие-то проблемы в этом случае пр. работе с гиьернейтом?

У тебя и в джаве будут проблемы с этим. Hibernate хочет работать с одним и тем же инстансом, и доступаться до полей напрямую.

а no-arg-конструктор больше не нужен?

Всякие коллбеки, которые передаются фреймворкам — это тоже IoC, и опять же если написать собственноручно реализацию forEach, она будет основана на IoC.

а no-arg-конструктор больше не нужен?

Нужен

то есть с неизменяемыми объектами он всё ещё не работает?

У тебя и в джаве будут проблемы с этим. Hibernate хочет работать с одним и тем же инстансом, и доступаться до полей напрямую.

сук, пол проекта менять

сук, пол проекта менять

возьми jooq

то есть с неизменяемыми объектами он всё ещё не работает?

и не будет я так думаю

у меня проблемы начались, толко после появления entity с составным ключом

инетересно почему

А я не вижу проблем. Для самой сути DI не особо важно, КАК собирается граф, важно, что всем клиентам извне поставляются их зависимости. Ну и как верно выше заметили, IoC вообще абстрактнее этого всего.

Хорошо, как тогда нам разделить говнокод в main и код когда spring пробежался по анноташкам и построил граф.

Всякие коллбеки, которые передаются фреймворкам — это тоже IoC, и опять же если написать собственноручно реализацию forEach, она будет основана на IoC.

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

но он ведь в java, то что нет new не означает что он без него обходится внутри

Бери глубже, внутри транзисторы открываются и заерываются

Хорошо, как тогда нам разделить говнокод в main и код когда spring пробежался по анноташкам и построил граф.

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

но он ведь в java, то что нет new не означает что он без него обходится внутри

Нев это выделения памяти и вызов первого метода, называет еще инит методом, по простому конструктор

Хорошо, как тогда нам разделить говнокод в main и код когда spring пробежался по анноташкам и построил граф.

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

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

Ну как, Если у меня 100 объектов, то это минумум 100 строк нежно раставленных в правильном порядке созданий объектов, объявление для них имем и прокидывание ниже по списку. Или одна строчка в которой будет написано просканируй вот эти классы и запусти код в определенном.

Ну как, Если у меня 100 объектов, то это минумум 100 строк нежно раставленных в правильном порядке созданий объектов, объявление для них имем и прокидывание ниже по списку. Или одна строчка в которой будет написано просканируй вот эти классы и запусти код в определенном.

И те же 100 строк будут сгенерены компилятором (и размазаны на 150 классов в случае даггера) / заменены на 100 рефлексивных операций.

В чём разница принципиальная?

В том, что это делается не руками? Ну я об этом и говорю, DI с применением фреймворка и DI руками.

DI оно от этого быть не перестаёт-то

И те же 100 строк будут сгенерены компилятором (и размазаны на 150 классов в случае даггера) / заменены на 100 рефлексивных операций.

Ну фишка в том что я декларативно описываю что хочу получить и получаю. А не императивно строю ручками граф. И в первом случае декларативно хорошо скейлится, а второе - постоянная поддержка.

Ну фишка в том что я декларативно описываю что хочу получить и получаю. А не императивно строю ручками граф. И в первом случае декларативно хорошо скейлится, а второе - постоянная поддержка.

Дык это разница в деталях реализации одного и того же подхода.

Дык это разница в деталях реализации одного и того же подхода.

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

И те же 100 строк будут сгенерены компилятором (и размазаны на 150 классов в случае даггера) / заменены на 100 рефлексивных операций.

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

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

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

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

Священная война началась.

Может уже хватит ?