Разбор ООП с Delphinum

L!MP, можно, всегда нужно стараться не усложнять. У меня есть проекты на чистом процедурном, ибо надо было реализовать быстро и изменений в проекте не предвиделось.

Mapper <-> Entity, тобишь в Mapper есть Entity

Ого. Ну то ты сам себе злобный Буратино

# L!MP (17.11.2016 / 14:41)
Я понятия не имею про эти ваши фабрики и если начну представлять, то наверняка представляю что то совсем не то.

Как оно там работает вообще? Ты пишешь конфиг, библиотека генерирует на основе него с

Ааа, нет, если ты пишешь библиотеку, обычно ты же с ней поставляешь и фабрику. в которой уже реализована нужная логика.
как пример: возьмем любой новый пакет из зенда: Для примера рассмотрим Сессии.
В современном подходе (касается и Зенда и Ауры и пимпле) класс должен быть инвокающийся, или же просто функция.
В вышеприведенном примере, для работы с сервис-локатор контейнером у нас есть https://github.com/zendframewo ... p#L64

Те же яйца, но вид сбоку, на примере JohnCMS: https://github.com/john-cms/jo ... p#L22
Несмотря на то, что сама фабрика может быть довольно сложной и реализовывать серьезную бизнес-логику (на примере JohnCMS - это аутентификация), реальный коннект к контейнеру - это __invoke()
Он в данном случае выступает вместо __construct(), контейнер дергает именно его.

# Delphinum (17.11.2016 / 14:45)
Есть у меня проект, в котором я своими руками (да не будет мне прощения) реализовал зависимость вида Mapper <-> Entity, тобишь в Mapper есть Entity, а в Entity есть Mapper. Рекурсивная зависимость, ма

Ну это и есть циклическая зависимость: объект А требует объект Б который тоже требует объект А в результате бесконечная рекурсия.
Решается с помощью прокси классов.

L!MP, ну я к тому, что и у DI есть свои ограничения, и у SL. Альк верно сказал, DI это SL + инициализатор, умеющий вставлять в запрашиваемые сервисы их зависимости. Тобишь из SL можно легко реализовать DI с помощью 1-2 доп классов.

А, ну так фабрика это получается сервис провайдер.

L!MP, прокси дебажить нереально ) О тестировании такого я вообще молчу, а взрослые IT компании не пустят твой проект в продакшн без юнит-тестов к нему, тим лид просто скажет - переписывай.

# L!MP (17.11.2016 / 14:52)
Ну это и есть циклическая зависимость: объект А требует объект Б который тоже требует объект А в результате бесконечная рекурсия.
Решается с помощью прокси классов.

Вот тут вина разработчика
Все объекты должны требовать зависимости не напрямую, а от DI контейнера, раз уж ты их (объекты) к нему подцепляешь. А кошерный контейнер не допустит рекурсий.

L!MP, если говорить совсем просто, то фабрика это:

$locator->set('MyService', function(){
  $service = new MyService(...);
  ...
  return $service;
});

$service = $locator->get('MyService'); // вызывается объявленная функция, которая создает и возвращает объект. В $service попадет то, что вернет эта функция

# Delphinum (17.11.2016 / 14:55)
L!MP, прокси дебажить нереально ) О тестировании такого я вообще молчу, а взрослые IT компании не пустят твой проект в продакшн без юнит-тестов к нему, тим лид просто скажет - [url=http://risovach.ru

Прокси компилируемый, т.е это реальный класс.
Вот, например : https://github.com/Ocramius/ProxyManager