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

10 минут назад написал

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

если бы это было фактом, срача не было бы

Именно

Ну да, пока это коллективная исповедальня

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

Ну "классы" то есть

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

и тут опять конструктор не DI

10 минут назад написал

Это не DI и я уже сказал, почему

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

они сами себе противоречат

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

^

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

+

Всем Kotlin, посоны.

Всем Kotlin, посоны.

Дэс

Уф, притихло. ?

Это было жёстко конечно

половина срача основана на споре DI != DI-контейнер vs DI == DI-контейнер не надо так. Договритесь о терминологии

Это не DI и я уже сказал, почему

> In object-oriented programming (OOP) software design, dependency injection (DI) is the process of supplying a resource that a given piece of code requires. Вот скажи мне что конструктор сюда не подходит

Ну DI поставляет готовые объекты и скрывает работу по их созданию

Делает ли это конструктор?

Немного нет

Если вы планировали обсуждать текущие реализации - надо было говорить об этом, а не о DI в целом:)

Кто поставляет? Какие объекты? Цитату же уже привели, что DI — это *процесс* инъекции зависимостей.

Кто поставляет? Какие объекты? Цитату же уже привели, что DI — это *процесс* инъекции зависимостей.

Хорошо, пусть так:)

А теперь давайте сраться о том, нужны ли DI-контейнеры.

Поехали :D

А теперь давайте сраться о том, нужны ли DI-контейнеры.

Ну, я пошел?

Дак мы об этом же и срались ?

Я вот с этим тезисом согласен — не все об этом срались

половина срача основана на споре DI != DI-контейнер vs DI == DI-контейнер не надо так. Договритесь о терминологии

Я вот с этим тезисом согласен — не все об этом срались

☝️

половина срача основана на споре DI != DI-контейнер vs DI == DI-контейнер не надо так. Договритесь о терминологии

Ну дак да, не понятно почему люди проводят знак равенства

Я напомню, с каких формулировок сия дискуссия началась — а дальше сами решайте, кто, что и как называет и кто что с чем путает :)

Ну вот ради простоты тестирования это всё и делается. Сложно отлаживать мы в JVM мире, с его DI, процессингом аннотаций в рантайме и прочим, уже получили и так ?

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

Что там в DI сложно отлаживать) Для проекта больше 30 классов и одного разработчика DI must-have.

DI в текущем виде - это как раз про то, как намертво склеить чистые вычисления с сайд эффектами в один монолитный комок Если что, в Хаскеле тоже вполне есть DI, я тут пробовал замокать IO монаду для тестирования main - вполне себе мокается для тестов, при этом в проде остаётся вполне себе IO

мне интересно, что мешает поднять тестовый контекст с моками, который заинжектится? что там отлаживать то сложно...

Всем привет! Нужно, чтобы в строке текст автоматически начинался с большой буквы, есть что-то типа toLower/UpperCase для этого? Или у кого пример есть. Заранее спасибо

Какой нибудь capitalString

Всем привет! Нужно, чтобы в строке текст автоматически начинался с большой буквы, есть что-то типа toLower/UpperCase для этого? Или у кого пример есть. Заранее спасибо

Ты не поверишь, String.capitalize() :)

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/capitalize.html

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

+

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

+

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

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

Делает ли это конструктор?

Билдер ?

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

Даже если так рассматривать - лучше к конфигурации, чем к коду:)

Даже если так рассматривать - лучше к конфигурации, чем к коду:)

Сказал программист который не пишет код...

Даже если так рассматривать - лучше к конфигурации, чем к коду:)

А конфигурация — не код?

Сказал программист который не пишет код...

Я ни разу не сказал, что не пишу код:)

А конфигурация — не код?

Конфигурацию проще поменять, чем код

Конфигурацию проще поменять, чем код

какая разница, поменять имя квалифаера или имя класса после new?

только в последнем случае получаем проверку типов и прочие плюшки

Я ни разу не сказал, что не пишу код:)

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

какая разница, поменять имя квалифаера или имя класса после new?

Как минимум в том, что при изменении конфига не нужно всё перекомпилить:)

Как минимум в том, что при изменении конфига не нужно всё перекомпилить:)

то есть конфиг — не код? XML?

какая разница, поменять имя квалифаера или имя класса после new?

Большая, 2м случае рефлекторного создания объекта не будет

то есть конфиг — не код? XML?

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

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

Так что юзаешь всё-таки?

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

Но твой конфиг в итоге в коде

А вообще, не то обсуждали и я сразу сказал - это только если подходить к вопросу с точки зрения конфигов

Но твой конфиг в итоге в коде

Каким боком?

Я ж рефлексию не использую

Еще раз - ушли от темы

Я ж рефлексию не использую

Ты можешь наконец сказать, что используешь? А то сферическое рассуждение в вакууме — XML нечасто, конфиг не в коде, рефлексии нет. А что есть?

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

Я так понимаю, речь тут про некоторую реализацию, работающую на конфиге, а я не говорил о реализации, я сказал, что с точки зрения солида new, использованный в явном виде вне класса/(чего-то еще)-инкапсулятора - нарушение

Ты можешь наконец сказать, что используешь? А то сферическое рассуждение в вакууме — XML нечасто, конфиг не в коде, рефлексии нет. А что есть?

Вы когда пом меняете - вы меняете код?:) когда вы пишете в конфиге вместо 1000 - 2000 вы меняете код? Вы меняете то, какую логику выбирает ваш код

ERROR: S client not available

А не сам код

Или я путаю что-то?

Вы когда пом меняете - вы меняете код?:) когда вы пишете в конфиге вместо 1000 - 2000 вы меняете код? Вы меняете то, какую логику выбирает ваш код

пом — это конфиг, Maven — DI-фреймворк?

Конечно, если у вас рефлексия во все поля и кодогенерация на лету - тогда да

пом — это конфиг, Maven — DI-фреймворк?

А при чем тут DI он или нет? Вы мне затираете про то, что конфиг - это код, так вот пом - такой же конфиг, как и любой другой и при этом никакой код там не меняется

Объясните, чего я не понимаю

Я так понимаю, речь тут про некоторую реализацию, работающую на конфиге, а я не говорил о реализации, я сказал, что с точки зрения солида new, использованный в явном виде вне класса/(чего-то еще)-инкапсулятора - нарушение

вот это как раз про 50 параметров конструктора

Объясните, чего я не понимаю

мы как будто называем одни слова, а имеем в виду вообще разные явления

мы как будто называем одни слова, а имеем в виду вообще разные явления

Может быть

Используя new вы явно говорите, что создать. Если это не делается чем-то, специально для этого предназначенным (не конструктором, а некоторым абстрактным менеджером, классом, DI, еще чем-то) - это нарушение. Я только об этом

Точке входа позволено это делать. Всё, проблема исчерпана.

Точке входа позволено это делать. Всё, проблема исчерпана.

Если вы про конструктор - нет, конструктор не определяет, какую реализацию интерфейса вы будете использовать, он только инициализирует объект

Если вы про конструктор - нет, конструктор не определяет, какую реализацию интерфейса вы будете использовать, он только инициализирует объект

Я про точку входа. public static void main.

Я так понимаю, речь тут про некоторую реализацию, работающую на конфиге, а я не говорил о реализации, я сказал, что с точки зрения солида new, использованный в явном виде вне класса/(чего-то еще)-инкапсулятора - нарушение

Я чот не вдупляю, где new нарушает solid? Это же просто функция (args...) => A

Я про точку входа. public static void main.

А, ок

Я чот не вдупляю, где new нарушает solid? Это же просто функция (args...) => A

Если ты зависишь от чего-то - ты не должен знать, чем это реализовано, если ты создаешь что-то через new - ты явно указываешь, что создавать, то есть знаешь, через что оно реализовано

Ладно, видимо, закрыли:)

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

Если ты зависишь от чего-то - ты не должен знать, чем это реализовано, если ты создаешь что-то через new - ты явно указываешь, что создавать, то есть знаешь, через что оно реализовано

Ты не понял, о чем говорит 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-контейнер не нужен, достаточно фабрики

Ты не понял, о чем говорит 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-контейнер не нужен, достаточно фабрики

А, понял

Согласен

Алилуя

а все это увлечение DI контейнерами из-за того что терминологию используют неточно. Да, жить без DI нельзя, а вот без DI-контейнеров можно

а все это увлечение DI контейнерами из-за того что терминологию используют неточно. Да, жить без DI нельзя, а вот без DI-контейнеров можно

☝️

Спасибо

а все это увлечение DI контейнерами из-за того что терминологию используют неточно. Да, жить без DI нельзя, а вот без DI-контейнеров можно

@HeapyHop вот заменил бы DI на IoC, а DI-контейнеры — на DI.

dependency inversion != dependecy injection

Ну началось, теперь еще за сокращения потрём

dependency inversion - инет говорит что это DIP

dependency inversion != dependecy injection

А ты прав. Constructor injection и IoC(DI) это все буква D в SOLID

Что-то я часто по делу, но неправильно поправлял