Разбор ООП с Delphinum

Кстати да, если вы не пользуете юнит-тестами и полиморфно не заменяете сервисы, то не вижу смысла вообще использовать SL или DI )

# Delphinum (17.11.2016 / 14:28)
Кстати да, если вы не пользуете юнит-тестами и полиморфно не заменяете сервисы, то не вижу смысла вообще использовать SL или DI )

не пользуете юнит-тестами

не пользуемся, ибо геморой

полиморфно не заменяете сервисы

Слишком "плоское" определение. Сервис-локатор сам по себе относительно небольшой класс.
По сравнению с автоматическим DI вообще мизер.
Посему, заменять его на какую-то статику. или что другое нет смысла, тут все просто и понятно.

# Delphinum (17.11.2016 / 14:23)
L!MP, чем искать первоисточник я лучше здесь напишу эти условия:
1. Рекурсивные зависимости - современные DI решения хоть и могут с ними справляться, но бывают такие сложные зависимости, что быстрее

1. Да же не знаю, ты о циклических зависимостях? Их контейнеры вообще решать не умеют, только с помощью ленивой инициализации через прокси.
В остальном, я не думаю что там какая-то серьезная проблема есть кроме скорости рекурсивных вызовов.
2. Ну да, тут согласен. Много мороки с компилированием контекста, замыканий, уже инициализированных классов (что там, сериализировать их или как вообще).
3. А чем в отладке отличается сервис локатор, от скомпилированного, аля симфони, контейнера? Там же считай он и есть.

# L!MP (17.11.2016 / 14:33)
А чем в отладке отличается сервис локатор, от скомпилированного, аля симфони, контейнера? Там же считай он и есть.

Ну грубо говоря - похоже, просто этот скомпилированный вариант еще надо распарсить и в итоге применить к сервис-локатору (что у любого DI в основе и есть), что ведет за собой накладные расходы.
не проще ли сразу применить SL + фабрики?

Да, некоторый напряг (на первый взгляд) с написанием этих самых фабрик, но зато предсказуемость, кликабельность и отлаживаемость берут свое!

# AlkatraZ (17.11.2016 / 14:33)
не пользуемся, ибо геморой

Тебе для движка юнит тесты вообще не нужны так как тестировать то толком не чего.
Там тогда уж функциональные тесты будут к стати.

# L!MP (17.11.2016 / 14:37)
Тебе для движка юнит тесты вообще не нужны так как тестировать то толком не чего.
Там тогда уж функциональные тесты будут к стати.

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

# AlkatraZ (17.11.2016 / 14:37)
Ну грубо говоря - похоже, просто этот скомпилированный вариант еще надо распарсить и в итоге применить к сервис-локатору (что у любого DI в основе и есть), что ведет за собой накладные расходы.
не пр

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

Как оно там работает вообще? Ты пишешь конфиг, библиотека генерирует на основе него сервис локатор? Он физический или виртуальный (аля регистри)?

Как там обстоят дела с определением содержания, авто дополнением?

# AlkatraZ (17.11.2016 / 14:33)
Слишком "плоское" определение. Сервис-локатор сам по себе относительно небольшой класс.
По сравнению с автоматическим DI вообще мизер.
Посему, заменять его на какую-то статику. или что другое нет см

Я не о замене SL на другой SL, а о замене какого то сервиса в этом SL на аналогичный, но с другой реализацией. На пример замена одного Logger (пишущий в файл) на другой Logger (пишущий в базу). Если таких замен нет и не предвидится, то смысла использовать SL я не вижу, так как можно сделать Logger тупо глобальным и везде пользовать его (говнокод но все же).

# Delphinum (17.11.2016 / 14:42)
Если таких замен нет и не предвидится, то смысла использовать SL я не вижу

Ну так то можно и не увидеть смысла использовать ООП вообще, гг.

# L!MP (17.11.2016 / 14:33)
1. Да же не знаю, ты о циклических зависимостях? Их контейнеры вообще решать не умеют, только с помощью ленивой инициализации через прокси.

Есть у меня проект, в котором я своими руками (да не будет мне прощения) реализовал зависимость вида Mapper <-> Entity, тобишь в Mapper есть Entity, а в Entity есть Mapper. Рекурсивная зависимость, мать ее. Обычный DI не смог разрешить эту зависимость, пришлось переходить на SL и руками ее разрешать.