Внедрение зависимости c Inversion

[@chEbba]

Конечно, к сервис ориентированной архитектуре (SOA) это имеет достаточно отдаленное отношение.

В чем преимущество перед указанными «соперниками»? В чем тяжесть симфоневской реализации? Почти уверен что при при дампинге в класс sf di выиграет достаточно много.

Прототипы через клонирование не лучший вариант. Как отдельная фишка — мб, но в основе должен быть вариант простого пересоздание сервиса.

В общем, пока не понятно «зачем».

[@Elfet]

Мне в моём проекте нужен был DI, я взял естественно то с чем уже знаком из Symfony, но он мне не подходил, после работал с Pimple, но в нём не хватало функциональности. Я решил создать что-то среднее между ними. Вот «зачем» :)

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

[@janson]

Чем именно для вас эта библиотека оказалась лучше чем Pimple?
И почему не подходил компонент из Symfony?

Эти мелочи могут стать важным звеном при оценке библиотек.

[@sybrex]

Долго смотрел на картинку и не мог понять, что же в ней не так :)

[@Davert]

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

class DIC {

function getService1()
{
    return new Service1();
}

function getService2()
{
    return Serivce2($this->getService1());
}
}

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

Минусы: чуть сложнее реализовать LazyLoading и… Дописывайте в комментариях )

[@Elfet]

Начинают все с простой реализации, затем добавляют LazyLoading и… через несколько интераций приходят к своему DI. :)

[@Davert]

Ну просто ваш DIC для меня принципиально ни чем не отличается от обоих DIC, что сделал Фабьен.
Чего бы лично мне хотелось от DIC: меньше всякой магии. Ибо такие контейнеры подобны фокусникам, что вытаскивают кролика из шляпы.

[@retran]

Потому что у вас не DI-контейнер, а Service Locator. И это антипаттерн.

[@sectus]

> Потому что у вас не DI-контейнер, а Service Locator. И это антипаттерн.

Покажите, пожалуйста, недостатки подхода, который предложил Davert, которые отсутствуют при использовании библиотеки, которую, например, предоставил Elfet.

[@Elfet]

Пусть у меня где-то в каком-то классе идёт следующий код:

$dic = new DIC();
$service1 = $dir->getService1();

Кроме как заменить new DIC() на свой класс унаследованный от DIC не получиться.

[@retran]

Не-не-не, не надо такого кода, это тот же самый Service Locator. Это ничем не отличается от просто фабрики или даже вызовы конструктора и здесь нет инверсии зависимости.

blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

А по поводу кода Davert`a — хороший DI-контейнер еще позволяет управлять жизненным циклом создаваемых объектов и задавать все зависимости в одном месте.

[@Davert]

В одном классе = в одном месте. Ну можно расширить класс. А ещё модно всяких смешных трейтов навесить.
Всё лучше чем по конфигурациям лазить.

[@Davert]

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

[@Davert]

Исходя из логики в статье
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.

DIC ничем не лучше.

[@retran]

C DIC у вас зависимости прописаны в конструкторах. В языках со статической типизацией падать будет в compile time.

[@Davert]

Стоп, а сервисы всё равно вытаскиваются из контейнера через get.
И вот в этот момент get'а будет происходить магия и падение.

[@retran]

Нет. get типизован под конкретный тип. Как именно типизован — зависит от конкретного языка. Но тип есть и его проверка произойдет при компиляции.

(я еще раз зачему, что это верно для языков со статической типизацией).

[@Davert]

В Symfony2 get типизирован под… вообщем никак он не типизирован. То же и в Pimple.
В чем собственно и печалька.

Потому я считаю, что так строить контейнеры нельзя.

Из всех вариантов я вижу 2:
— статически строить контейнер и дампить в файл. Но чтобы метода доступа к сервисам всегда были публичными.
— строить контейнер ручками.