сейчас набросаю

http://pastebin.com/G6Unu8T4

такой пример?)

это все подходы IoC

в первом случае инъекция зависимостей, во втором сервис-локатор

почему ты первое назвал сервис-локатором не ясно

http://pastebin.com/0nXZGU2W

перепутал простите

:D

писал одно думал о другом)

первое - DI, второе локатор

все они IoC

тогда что такое IOC ?

inverse of control это изменение чего то )

когда зависимости по разному создаются )))

если расмотреть di как конкретная реализация

и сделать service locator и ioc это принципы

тогда было бы понятней но э

это не совсем правда)

как правильно?

может кто то объяснить на примере

показать пример ioc и сказать это ioc потому что вот это вот так

похоже меня только одного интересует этот вопрос(

Своими словами объясни что такое инверсия контроля. Это оно и есть.

Не в контексте программирования

ну я выше писал

это когда управление меняется)

и разное управление возвращает разный результат)

просто я хочу знать когда в проекте

IOC, DI, ServiceLocator )

Это когда компонент инвертирует контроль за своими зависимостями. Сначала компонент сам их контролирует, а инвертировав, перекладывает это на пользователя.

Это подход. И этот подход может быть реализован с помощью di

ну получается что я написал в коде

просто все зависит от реализации di

ну получается что я написал в коде

ну ты там чего-то намешал, что частично верно, частично нет

ioc - это инверсия контроля за зависимостями di - это когда ты зависимости внедряешь (инджектишь) для инверсии контроля service locator - это паттерн, позволяющий держать инстансы сервисов в одном реестре все вместе это разные вещи, но могут решать проблемы друг друга

service locator - это паттерн, позволяющий держать инстансы сервисов в одном реестре а что за паттерн тогда registry ?

потому что отличие service locator от di очень хорошо описано здесь https://martinfowler.com/articles/injection.html

загугли) реестр - это по-моему обычное понятие из риал лайф - его не надо объяснять

так есть паттерн

Registry как и service locator

только отличие в том что в начале все объекты создаются а потом возвращается один и тот же результат

а в случае с service locator объект создается в момент когда ты его запрашиваешь

нету предварительно этапа создания

Registry это любое key, value хранилище

потому что отличие service locator от di очень хорошо описано здесь https://martinfowler.com/articles/injection.html

ты путаешь di с помощью SL от SL. по ссылке первое

так там говорится вот возьмем di

если мы внедряем готовый результат (объекты) это будет di

если мы передаем сам объект который получает результаты и там уже внедряем

Registry это любое key, value хранилище

именно. service locator оно и есть - ты же по ключу запрашиваешь

то это service locator

именно. service locator оно и есть - ты же по ключу запрашиваешь

так разница в том что объекты в регистре уже объявлены

так разница в том что объекты в регистре уже объявлены

не мешай все в кучу. реестр - это просто реестр. kv сторадж.

частная его реализация - SL

точнее не реализация, а частный вариант использования

а в случае с service locator объект создается в момент когда ты его запрашиваешь

не всегда. ты можешь ioc контейнер взять и заюзать как сервис локатор

@fes0r так расскажешь про модули?(

?

не всегда. ты можешь ioc контейнер взять и заюзать как сервис локатор

ну в примере кода он брался

и использовался как SL

или получается так

http://pastebin.com/kxgCLEGh

вот более подробно написал

ты все не поймешь: di и ioc - принципы. у них не может быть интерфейсов.

хорошо di и ioc принципы

sl тоже принцип ?

вот тебе принцип - будь хорошим. Это не значит, что должен быть GoodInterface

ERROR: S client not available

sl тоже принцип ?

это паттерн

хорошо это паттерн

di принцип говорит пиши классы как в MagicDI ?

dependency injection - инжектируй зависимости.

ну пусть $ioc будет тот кто инжектирует

если рассматривать MagicDI, то да, оно

хорошо а SL паттерн

но фаулер говорит если у вас SL пишите в этом стиле

в стиле MagicSL

и там графики зависимостей

он говорит что можно вместо отдельных зависимостей инжектировать целый контейнер.

и приводит минус SL что ваш MagicSL зависит помимо a и b он еще зависит от интерфейса ServiceLocatorInterface ну или как в примере IoCInterface

это говорит паттерн или принцип?

сам по себе SL не про инжектирование контейнера, а про реестр сервисов

ок я понял о чем ты

так реестр сервисов может быть в стиле DI из примера MagicDI

ок я понял о чем ты

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

да это я давно понял)

что это плохо

получается у тебя есть MagicDI

и есть какой объект который может его создать (ServiceLocator)

ну и вот. То что ты называешь MagisSL - это пример антипаттерна, а не как работает SL

ок я понял это я написал

так ?

получается у тебя есть MagicDI

и есть какой объект который может его создать (ServiceLocator)

что такое MagiDi? сервис из SL?

ну из примера объект

пример как описывать классы без антипатерна

service locator создает только сервисы, которые в нем находятся (и то скорее в нем фабрики, которые создают сервисы)

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

ну ок, констурктор