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

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

G>>Это пусть в никуда. Параметров станет слишком много раньше чем вы рассчитываете,
·>Это путь надёжного кода.
Ага, и его огромного количества

·>А что плохого в большом количестве параметров?
В том что это код, который нужно поддерживать и он может в том числе ошибки содержать.

·>Хорошо в том, что код проверяется компилятором, удобно навигируется в IDE и даже если вдруг понадобилось — проходится отладичком и т.п.
В asp.net тоже все хорошо работает.

G>>а добавление сервиса станет адом.
·>Не станет. С чего вдруг? Хотя если у вас у каждого сервиса десятки зависимостей, то да.. Но это не "станет адом", а покажет какой же у вас ад в архитектуре.
С того, что если тебе понадобилось добавить сервис, то надо сделать в дух местах: в конструкторе самого класса и в месте его создания.
Кроме того, в веб-пиложенияъ время жизни объекта может быть разное и, соотвественно, код создания объектов будет в нескольких местах. И тебе надо еще не перепутать куда добавлять.

G>>Собственно поэтому и появились синглтоны в плюсах, а в языках с рефлексией и метаданными — DI.
·>Синглтоны появились как логическое продолжение глобальных переменных, думаю из тех времён, когда локальные переменные ещё не придумали.
Интересно когда по твоему придумали локальные переменные, паттерны и языки высокого уровня.

·>Ты тоже путаешь DI и IoC-конейнер. DI — нужен и ему не нужна рефлексия. Мой код выше — с DI. IoC-конейнер — не нужен.
DI в масштабе даже веб-фреймфорка без контейнера, который этот DI автоматизирует, не взлетит. Ну просто синглтоны везде будут (как в ASP.NET до MVC, OWIN и Core).

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

G>>>Это пусть в никуда. Параметров станет слишком много раньше чем вы рассчитываете,
Р>·>Это путь надёжного кода. А что плохого в большом количестве параметров?
Р>Зачему, что параметр может быть один(типа конекста). кложуристы так любят делать.
Р>их хеш-мапа форсит так делать, ибо легко ключики добавляются.
Та же глобальная переменная, вид в профиль. Непонятно зачем так делать.

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

G>·>Это путь надёжного кода.
G>Ага, и его огромного количества
Откуда огромное количество?

G>·>А что плохого в большом количестве параметров?
G>В том что это код, который нужно поддерживать и он может в том числе ошибки содержать.
Код с фреймворком тоже надо поддерживать. Внезапно. И ошибки там искать на порядок сложнее.

G>·>Хорошо в том, что код проверяется компилятором, удобно навигируется в IDE и даже если вдруг понадобилось — проходится отладичком и т.п.
G>В asp.net тоже все хорошо работает.
Ага. Как всегда — почти.

G>>>а добавление сервиса станет адом.
G>·>Не станет. С чего вдруг? Хотя если у вас у каждого сервиса десятки зависимостей, то да.. Но это не "станет адом", а покажет какой же у вас ад в архитектуре.
G>С того, что если тебе понадобилось добавить сервис, то надо сделать в дух местах: в конструкторе самого класса и в месте его создания.
И? Две строчки кода. IDE это делает автоматически, ибо это классический рефакторинг introduce parameter.

G>Кроме того, в веб-пиложенияъ время жизни объекта может быть разное и, соотвественно, код создания объектов будет в нескольких местах.
Прям ужас! Надо же — разные вещи предлагается раскладывать в разные места! Слишком не по-индусячьи что-ли?

G>И тебе надо еще не перепутать куда добавлять.
Если перепутаешь — код тупо не скомпилится. В случае фреймворка — падение будет в рантайме.

G>>>Собственно поэтому и появились синглтоны в плюсах, а в языках с рефлексией и метаданными — DI.
G>·>Синглтоны появились как логическое продолжение глобальных переменных, думаю из тех времён, когда локальные переменные ещё не придумали.
G>Интересно когда по твоему придумали локальные переменные, паттерны и языки высокого уровня.
Я ещё тогда не родился.

G>·>Ты тоже путаешь DI и IoC-конейнер. DI — нужен и ему не нужна рефлексия. Мой код выше — с DI. IoC-конейнер — не нужен.
G>DI в масштабе даже веб-фреймфорка без контейнера, который этот DI автоматизирует, не взлетит.
Взлетают и летают.

G>Ну просто синглтоны везде будут (как в ASP.NET до MVC, OWIN и Core).
Если синглтоны не писать, то сами они не появятся.

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

·>Здравствуйте, Разраб, Вы писали:

G>>>>Это пусть в никуда. Параметров станет слишком много раньше чем вы рассчитываете,
Р>>·>Это путь надёжного кода. А что плохого в большом количестве параметров?
Р>>Зачему, что параметр может быть один(типа конекста). кложуристы так любят делать.
Р>>их хеш-мапа форсит так делать, ибо легко ключики добавляются.
·>Та же глобальная переменная, вид в профиль. Непонятно зачем так делать.

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

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

Замечу, что ООП-архитектуры часто сильно осложняют реализацию из-за привычки все время скрывать данные.
хотя по адресу всегда можно любую область памяти достать.

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

Р>>>Зачему, что параметр может быть один(типа конекста). кложуристы так любят делать.
Р>>>их хеш-мапа форсит так делать, ибо легко ключики добавляются.
Р>·>Та же глобальная переменная, вид в профиль. Непонятно зачем так делать.
Р>есть на ютубе некто николай рыжиков, говорит красиво. утверждает, что не он первый начал))
Р>принцип "открытый мир". т.к. кложа динамическая, разраб берет из мапы то что ему нужно(или кладет), не задумываясь о постороннем.
Именно, что динамическая. Там вопрос надёжности кода решается прогоном тестов. Я же говорю о wiring code как возможность иметь компайл-тайм проверки.

Использование IoC-фреймворков в ЯП со статической типизацией — это шаг назад, т.к. проверки уходят в рантайм. Но людям нравится, видимо, ловить ошибки в проде.

Р>надежность проверяется такой фичей как спецификации. точно не помню, но кажись они как тесты прогоняются в дебаге только.
Именно. И падает в проде, если правильный тест забыли написать.

Р>как результат — кода меньше, фичы разрабатываются быстрей.
Классическая троица: быстро, качественно, недорого. "Быстро" — ты уже использовал, получается что на кложе код либо некачественный, либо дорогой.

Р>Замечу, что ООП-архитектуры часто сильно осложняют реализацию из-за привычки все время скрывать данные.
В смысле сложнее выстрелить в ногу? Так это же хорошо.

Р>хотя по адресу всегда можно любую область памяти достать.
Ну от ЯП зависит, в яве адресов-то нет. Так что никак не достать.

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


Z>Здравствуйте!
Z>Подскажите как осуществляется начальная инициализация ("сборка") всех зависимостей в приложении, построенном с помощью подхода DDD?

По-моему, вы описали как работает фреймворк Spring в Java https://spring.io
Там сам фреймворк управляет объектами ("бинами"), отслеживает зависимости и внедряет то, что нужно и куда нужно.