·>Если зависимость уже есть в лексическом скопе, то тоже всё сразу заработает. Если нет — надо будет поглядеть почему и сразу заметить, ситуацию когда её не должно быть. Например, нечаянно не создашь циклическую зависимость или не смешаешь слои.

Я говорю только в контексте C#/Java. По функциональщине (а терминология по lexical scope я так понимаю сейчас всплыла скорее оттуда) не готов обсуждать, мало опыта. Но если поделишься подробным пояснением, что имел в виду — буду благодарен, это мне интересно.

p>> Если не зарегистрирована — приложение упадёт с исключением при первом запуске
·>Не понял в чём плюс. Ошибки в рантайме — плюс?

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

·>Когда как. Вон там выше чувак вытаскивает зависимости через serviceLocator.Get<Some>().

Ну то такое. Не в концепции "конфигурации", которую я описывал выше, это уже на его совести.

·>Что за вызывающий код? Этот вызывающий код и есть composition root, т.е. описание структуры зависимостей твоего приложения. Отличая дока, кстати.

Вот-вот, он. Его придётся частенько дописывать (C#/Java).

·>Да, по сути это целый DSL, притом динамический, и со стандартами плохо.

Есть такое, да.

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

p> ·>Если зависимость уже есть в лексическом скопе, то тоже всё сразу заработает. Если нет — надо будет поглядеть почему и сразу заметить, ситуацию когда её не должно быть. Например, нечаянно не создашь циклическую зависимость или не смешаешь слои.
p> Я говорю только в контексте C#/Java. По функциональщине (а терминология по lexical scope я так понимаю сейчас всплыла скорее оттуда) не готов обсуждать, мало опыта. Но если поделишься подробным пояснением, что имел в виду — буду благодарен, это мне интересно.
Нет, я имел в виду, что если у тебя есть:

var dao1 = new Dao1(db);
var dao2 = new Dao2(db);
var svc1 = new Svc1(dao1, dao2);
var svc2 = new Svc2(dao2);

То добавить dao1 в Svc2 никаких дополнительных правок не потребует.
Зато в Dao1 добавить svc1 у тебя просто не получится скомпилировать.

p> p>> Если не зарегистрирована — приложение упадёт с исключением при первом запуске
p> ·>Не понял в чём плюс. Ошибки в рантайме — плюс?
p> Ну, это же надо читать вместе с предыдущим предложением Да, тут будет ошибка в рантайме, но (далее по тексту).
Далее по тексту начинался новый параграф.. я не понял в чём "но".

p> ·>Когда как. Вон там выше чувак вытаскивает зависимости через serviceLocator.Get<Some>().
p> Ну то такое. Не в концепции "конфигурации", которую я описывал выше, это уже на его совести.
Да, но и в том числе и на совести фреймворков, что такой гнокод стимулируют писать как самое простое и очевидное решение.

p> ·>Что за вызывающий код? Этот вызывающий код и есть composition root, т.е. описание структуры зависимостей твоего приложения. Отличая дока, кстати.
p> Вот-вот, он. Его придётся частенько дописывать (C#/Java).
По большому счёту современные IDE этот код пишут сами. И это же супер, когда у тебя есть акнуальная дока, притом проверяемая компилятором.

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

b> Циклические зависимости есть. DI в упор не вижу. Ваше слишком общее утверждение опровергнуто.
var a = new A(){RefB = new B()}; — это и есть DI по определению (а конкретно property injection). Альтернативой будет либо

class A
{
    public B RefB = new B();
}

либо

class A
{
    private B RefB;

    public A(ServiceLocator sl)
    {
        RefB = sl.Get<B>();
    }
}

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

IT>>Не-не-не. Нам твои DI фреймворки нафиг не нужны и нам без них хорошо. Покажи, что мы не правы, приведи код, где DI фремворки рулят.
S>Ок, по сравнению со статическим синглтоном...

Где код?

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

IT>>При желании можно абстрагироваться даже от интерфейсов. Но я не буду говорить как, не дай боже вам это понравится.
S>Само собой не будете: вы уже который комментарий стесняетесь не то что код приводить, но даже хоть чуть-чуть в конкретику углубляться.

Вроде как код собираешься приводить ты, а не я.

Здравствуйте, Министр Промышленности, Вы писали:

AA>>>Взять теже фабрики, билдеры они тоже зло?
IT>>Да.
МП>не ну это преребор

Ну блин. Ты то должен был промолчать

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

IT>>Можно пример тестирования конфигурации Production?
SD>Поясни, что ты имеешь в виду. Тестируют не конфигурацию, а систему (SUT, system under test).

Цитирую оригинал

Более того, "конфигурирование" требует ровно того же тестирования, что и "кодирование", и ровно такого же процесса выкатывания изменений.

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

M>В данном случае при ошибке у нас будет стек трейс

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

M>Просто кейс что при использовании DI в конструктор передали null невозможен в принципе, тут нужен другой пример.

Пусть передали не null, а поломаный объект.

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

M>Так не пишут при использовании DI. Нужно постараться уйти от зависимости которую нельзя разрешить автоматически. Как вариант SourceType можно попробовать перенести из конструктора в DoSomeWork.

Т.е. какой-то там драный фреймворчик будет указывать мне, программисту с тысячелетним опытом как писать код???

SD>>Поясни, что ты имеешь в виду. Тестируют не конфигурацию, а систему (SUT, system under test).
IT>Цитирую оригинал
IT>

IT>Более того, "конфигурирование" требует ровно того же тестирования, что и "кодирование", и ровно такого же процесса выкатывания изменений.

И что тебе непонятно?
У тебя есть файл "исходный код".
У тебя есть файл "конфигурация".

Тебе нужно написать тесты на SUT, которая есть комбинация из "исходный код + конфигурация".

Если система плохо спроектирована (например, позволяет запускать 2 экземпляра, aka staging), эти тесты называются "health checks" (и подразумевают всякие там monitoring/observability/dashboards/alarms). Разумеется, поймать проблему на стадии "health check" тестов очень дорого (намного дороже, чем, скажем, на стадии CI или тем более статического анализа/компиляции).

AA>>>>Взять теже фабрики, билдеры они тоже зло?
IT>>>Да.
МП>>не ну это преребор

IT>Ну блин. Ты то должен был промолчать

я стараюсь быть объективным независимо от линии дискуссии

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

SD>И что тебе непонятно?

Мне непонятно как протестировать конфигурцию для продакшина.

Здравствуйте, Министр Промышленности, Вы писали:

IT>>>>Да.
МП>>>не ну это преребор
IT>>Ну блин. Ты то должен был промолчать
МП>я стараюсь быть объективным независимо от линии дискуссии

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

IT>>>>>Да.
МП>>>>не ну это преребор
IT>>>Ну блин. Ты то должен был промолчать
МП>>я стараюсь быть объективным независимо от линии дискуссии

IT>Ты в самом зародыше убил флейм, который выглядел весьма многообещающим.

и это правильно
я не ради флейма

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

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

_>Дальше, говорят что плюс в том что из любого места я могу получить(создать) любой инстанс. Но простите, в таком случае ваша архитектура превратилась в кучу глобальных переменных где Всё доступно Отовсюду. Как же тогда быть с принципами разграничений? В определенном месте кода должно доступно только то что необходимо, что передали явно, что доступно по ссылочным связям.

В рантайме — да, но в коде получаем отделение интерфейса от реализации. все зависимости "сшиваются" в одном месте.

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

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

AA>>Понял, а то у ТС вообще неопнятно на что он жалуется. ну это субъективно. так то во всех учебниках учат что надо избегать явного создания объектов.

IT>Они не учат почему этого нужно избегать? Если нет, то ввыкинь такие учебники на помоечку. Впрочем, если да, то тоже выкинь.

Чтобы не зависеть от реализации.

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

AA>>Взять теже фабрики, билдеры они тоже зло?

SD>Примененные где не надо — конечно, зло.

по мне так это философия. как только нужно расширить поведение объекта, так сразу возникает необходимость интерфейса и следовательно фабрики.
Кто-то делает это сразу. Кто-то в процессе рефакторинга. Это субъективно.

Да и вообще, оператор new не нужен в принципе. В куче ЯП его нет вообще. К чему эта магия?
Дельфи — :=Create("Alice"), лисп — (make-person :name "Alice"), f# let person = Person {Name = "Alice"}.

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

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

AA>>Здравствуйте, Министр Промышленности, Вы писали:

МП>>>а реальная необходимость бывает редко и всего в 2-3 местах системы

AA>>Очевидно, что DI это реализация принципа инверсии зависимостей.
AA>>Если у вас возникают циклические зависимости между компонентами, то вам не избежать DI.

_>

_>class A
_>{
_>    public B RefB;
_>}

_>class B
_>{
_>    public A RefA;
_>}


_>void Main()
_>{
_>    var a = new A(){RefB = new B()};
_>    a.RefB.RefA = a;
_>}

_>

_>Циклические зависимости есть. DI в упор не вижу. Ваше слишком общее утверждение опровергнуто.

Если классы окажутся в разных сборках код уже не соберется. Пока код в одной сборке из-за многопроходного компилятора это собирается.
F# однопроходный и там без явной рекурсии такое объявление не соберется.

Здравствуйте, varenikAA, Вы писали:
AA>Да и вообще, оператор new не нужен в принципе. В куче ЯП его нет вообще. К чему эта магия?
AA>Дельфи — :=Create("Alice"), лисп — (make-person :name "Alice"), f# let person = Person {Name = "Alice"}.
Вопрос не в операторе. В том же Delphi паттерн "фабрика" встроен прямо в язык — см. "виртуальный конструктор".

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

M>>Просто кейс что при использовании DI в конструктор передали null невозможен в принципе, тут нужен другой пример.
IT>Пусть передали не null, а поломаный объект.

Передали, и? Чем поведение без DI будет отличаться от поведения с DI в данном случае?