а di это подход созданию системы

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

ну или еше как то

service locator получается некая реализация

чего-то, что мы не обсуждаем. мы же про ioc и di?

а di это подход созданию системы

да

а что тогда такое ioc ? это тоже подход (принцип)

в чем он заключается

в том, чтобы не создавать инстансы зависимостей внутри компонента, а делегировать эту задачу клиенту компонента вне

ну сейчас у нас инстанты создаются внутри SL а не внутри MagicDI

получается MagicDI еще и IOC принцип

ioc можно реализовать с помощью di. Все. SL здесь не причем

хорошо антипатерн в виде MagicSL (кода из примера) он как бы тоже не нарушает IOC

получается

да

но он антипаттерн

сейчас пример напишу

http://pastebin.com/DFyiZrbU

вот пример нарушения принципы IOC

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

принцип IoC это почти принцип голливуда

ну это фабричный метод. а как тогда создавать объекты вообще?

ну за это пусть отвечает registry :D

вот пример нарушения принципы IOC

ты же зависимости там передаешь извне - почему это нарушение?

через конструктор сам создает и решает как)

а ну да пардон

просто голова уже повернута делать сразу правильнол

сейчас хотфиксану

вот сейчас http://pastebin.com/QFCMm21Q

но тогда встречный вопрос а это будет нарушением IoC

сейчас напишу

вот сейчас http://pastebin.com/QFCMm21Q

ну а что тут происходит? ты в констурктор строки передаешь.

http://pastebin.com/BnEr8rxA

ну а что тут происходит? ты в констурктор строки передаешь.

так то что в конструкторе строки это DI принцип

мы его не нарушаем

http://pastebin.com/BnEr8rxA

тут все ок.

это IoC не нарушает?

ты зависимости извне передаешь - все ок

http://pastebin.com/QFCMm21Q а тут нарушаю

зависимости внутри сам определяю

какие например?

я не вижу там зависимостей

ну например a

'a' и 'b'

это не зависимости. эито строки

так строка тоже зависимость

она же в конструктор подается

или зависимость только от объекта?

для подключения к бд нет разницы какой там dsn или username и password

разницы нет - строки извне же приходят

так это мы решили что если извне это DI

или нарушения IoC это вот этот ужас

так это и есть di - ты же инжектируешь зависимость

http://pastebin.com/gVJwkB38

а вот это уже фейл

ну это di я не отрицаю

последний пример феил DI это понятно

последний пример феил DI это понятно

это фейл ioc

ты продолжаешь путать понятия)

хорошо мб

так есть например spring

с его autowire

и там можно фигарить вот такие выкрутасы

я не знаю как это работает, но думаю там по аннтоации инжектится зависимость из контейнера

так это через reflection работает

в начале создается объект

через reflection берет reflectionMethod конструктора

так это через reflection работает

ну и ок. инъекция же

ERROR: S client not available

там смотрят зависимости (так как строгая типизация в java проблем нет)

потом смотрят свойства с autowire и через reflectionClass их проставляют

на основе типа или именованного свойста

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

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

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

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

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

ну и ок. инъекция же

но опять же антипаттерн, т.к. доьавляем внешнюю зависимость от реализации di

просто я много видел разработчиков и каждый по своему понимает di, ioc, sl

в целом похоже но в деталях очень по разному

на примерах это хорошо заметно

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

омг. все все еще за di топите)

некоторые di и dip путают

в особо запущенных случаях

омг. все все еще за di топите)

так проблема что четких определений нет, ну или я не видел

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

как нарушить ioc в классе

можно пример ?)

public class A { private B b; public A() { b = new B(); } }

да

http://pastebin.com/gVJwkB38

но в примере того же спринга

через autowire зависимость b вполне контролируется

public class A { @Autowire private B b; public A() { b = new B(); } }

через autowire зависимость b вполне контролируется

зависимость внутри создаешь или извне инжектится?

так в спринге она из вне будет

проставлятся после создания объекта

так в спринге она из вне будет

ну и?

в начале конструктор, потом inject зависимостей

я правда давно со spring не возился (pre release 3 версии)

public class A { private B b; public A() { b = new B(); } }

вот этот ахтунг все что можно вообще нарушает