Разбор ООП с Delphinum

# AlkatraZ (17.11.2016 / 14:15)
Читани каменты к Сисмфонии, глянь ауру и т.п. развивающиеся фреймворки, не попсу.

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

AlkatraZ, ну стандарт и рекомендация в контексте PSR почти синонимы. Стандарт ведь тоже никто не заставляет тебя соблюдать ) Хочешь следуй ГОСТу, хочешь двигайся в сторону ISO. Я считаю, что стандартов должно быть много и они должны конкурировать, а не делать из PSR догму, как сегодня пытаются многие.

# Delphinum (17.11.2016 / 14:17)
Тут дело не столько в Zend, они лишь привели несколько очень серьезных доводов в пользу отхода от DI, на основании которых и предложили отказываться. Но отмечу, что они не просто предлагают - откажите

А можно где-то почитать про те условия в которых сервис локатор лучше внедрения зависимостей?

# L!MP (17.11.2016 / 14:00)
Накой черт оно мне нужно если я РНР не собираюсь использовать не для чего иного кроме как stateless приложений?

У zend-diactoros есть одна очень интересная. но возможно ключевая особенность: весь Response к клиенту идет в стрим режиме, без напряга памяти сервера и т.д.

# L!MP (17.11.2016 / 14:20)
А можно где-то почитать про те условия в которых сервис локатор лучше внедрения зависимостей?

Я постараюсь найти ссылки на первоисточник (на английском).
Там же будет и агитация за config-driven, то есть, за построение системы на конфигах.

L!MP, чем искать первоисточник я лучше здесь напишу эти условия:
1. Рекурсивные зависимости - современные DI решения хоть и могут с ними справляться, но бывают такие сложные зависимости, что быстрее использовать для разрешения рекурсивных зависимостей именно SL
2. Скорость - большой проект требует сложной логики DI, при чем на самом старте. Применение кеша и компиляция частично решает эту проблему, но создает новую, а именно применение кеша и компиляция ))
3. Сложность в отладке и профилировании - те же точки останова в профилировщике часто (читать - всегда) не могут поймать баг в работе DI гденить в глубине

Из всего этого я сделал простой вывод - начинайте проекты с DI, если вы не знаете, насколько они вырастут в будущем и если вы можете легко заменить DI на SL, в противном случае сразу пользуйте SL.

# L!MP (17.11.2016 / 14:18)
И что я там должен увидеть? В симфони как был компилируемый в класс DI контейнер, так и остался. В ауре той, то же контейнер, правда я не помню есть ли там автовайринг или нет.

Между прочим, Зендовский класс той же направленности (тоже компилирующий + при желании сервис-локатро создающий) поудобнее.
---
Главный вопрос в том, что ТЫ и никто другой должен определять, ЧТО тебе отдаст контейнер.
А это решается фабрикой: там ты сам реализуешь любую нужную тебе логику и запилишь нужные зависимости.

# AlkatraZ (17.11.2016 / 14:22)
Там же будет и агитация за config-driven, то есть, за построение системы на конфигах.

Мы уже давно на агитации не ведемся, гг.
Ну а так то да, если получится, то найди, интересно почитать в особенности про преимущества сервис локатора.

AlkatraZ, он там компилируется, но совсем не так как симфони.
Хотя х.з, я зендом никогда не интересовался, так что могу не все знать.

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

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