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

это тебе был пример нарушения ioc

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

ну ты сам попросил )

я хочу пример кода чтобы он был di, но не был ioc

такое возможно ?)

нет

di - это способ решить вопрос ioc. по определению нет

хорошо наоборот, чтобы код был ioc но не был di ?)

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

хорошо наоборот, чтобы код был ioc но не был di ?)

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

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

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

сейчас скину на pastebin это уже станет ioc ?

ну тут пытаются объяснить уже. IoC - это подход, считай это как философия

"Я добираюсь на работу на транспорте" - это подход

на каком транспорте - это уже реализация подхода

Например, на машине - это di, на трамвае - это sl

Например, на машине - это di, на трамвае - это sl

нет. di и sl - это вообще разные вещи

di - да, способ. sl - просто параллельное понятие

да, пардон, не то написал

Хотя я кстати и с примером наврал, вот википедия говорит, что через конструктор передача параметра это тоже di

http://pastebin.com/PKyKuNh9

Хотя я кстати и с примером наврал, вот википедия говорит, что через конструктор передача параметра это тоже di

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

вот с такой доработкой это уже станет IoC

ну вот там на той же вики через фабрики предлагают )

вот именно

а если смотреть российскую вики

ну вот там на той же вики через фабрики предлагают )

а, ну да.

и english там еще больше разницы)

вот тут и начинается жопа)

все понимают но никто не может дать определения)

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

это код не di или не ioc ??)

это код di и ioc

ага вот я к тому и говорю

что привести пример di без ioc или привести ioc без di

но если такого примера нет

значит и разницы между ними нет

а если di - ioc = 0

то di = ioc

di без ioc нельзя, потому что di это ioc, а ioc без di элементарно

давай

я тут вместо работы холивар затеял)

связь между системами через ивенты

в виде кода если можно

между компонентами\модулями\классами

необязательно рабочего просто пример

реализация ивент-системы?

ну EventManagerItnerface

EventInterface

вопрос в коде-обработчике

или ты на js пишешь без интерфейсов)

di без ioc нельзя, потому что di это ioc, а ioc без di элементарно

+

public class A { private B b; public A() { this.b = BFactory.getB(); } }

использование фреймворка уже IoC

public class A { private B b; public A() { this.b = BFactory.getB(); } }

подобное я уже писал

только в пхп стиле, но суть понятна

хорошо получается по твоим словам ioc не отвечает за создание объекта

ioc это инверсия контроля, это про то, кто управляет потоком выполнения

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

использование стратегий - IoC

получается есть Observer

events - IoC

получается IoC это поведенческий подход

ну или поведенческий

а di это структурный

ну или порождающий

ioc - поведенческий подход, di - порождающий подход

так получилось?)

не знаю о чем ты)

ERROR: S client not available

ioc - это абстрактный подход к проектированию, сама идея

di - семейство однотипных конкретных реализаций этой идеи

помимо di есть еще другие семейства реализаций

не знаю о чем ты)

ну выше писали что di и ioc это подходы

ioc более общее понятие

включающее в себя di

di - семейство однотипных конкретных реализаций этой идеи

выше пришли к выводу что di - это тоже подход

а service locator это реализация ну или regist

во чего нашел

registry

https://habrahabr.ru/post/131993/

так есть и другие статьи на эту тему

говрящие другое

например?)

https://martinfowler.com/articles/injection.html

более авторитетное мнение чем, мнение какого то .net разработчика

я ничего плохого про .net не говорю или про автора статьи на хабре, просто у фаулера некий авторитет.

там по ссылке отдельно еще о https://martinfowler.com/bliki/InversionOfControl.html

причем обрати внимание на даты постов это 2004 год примерно

там по ссылке отдельно еще о https://martinfowler.com/bliki/InversionOfControl.html

There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.

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

в виде constructor, property, etc

setter injection, etc

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

просто мнений по этому поводу реально дофига)

просто мнений по этому поводу реально дофига)

нет никаких мнений

есть ioc, есть di как один из видов ioc, есть di через конструктор один из типов di

есть принцип - Inversion of Control, есть реализация - Dependency Injection

есть пафосное название - IoC Container

ну вон человек выше писал

что di это подход

здесь в чате