setter injection это подмножество di

service locator это подмножество ioc

а что есть в ioc чего нет в di ?

я написал про service locator

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

вообще вот почитай

в Ioc есть SL которого нет в DI

а что есть в ioc чего нет в di ?

service locator, factory, strategy и тд

я читал много раз

и эти ссылки сюда выкладывал

а что есть в ioc чего нет в di ?

немного некорректный вопрос, кмк

ну если утверждение что di подмножество Ioc

я хочу ioc - di посмотреть что за множество осталось

ну тебе ответили, другие сопособы реализации ioc - service locator, factory

просто преведущий кто объяснял уже не объясняет(

я хочу ioc - di посмотреть что за множество осталось

выше ж кучу раз написали, strategy, events, factory, sl

а новые не согласны с тезисами преведущего оратора

давай с простого sl, di, ioc это реализации, паттерны или подходы ?)

все подходы

хорошо все подходы

пишу пример

http://pastebin.com/q13nMcQA

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

и SL в его понимание это тот же registry

возможно он не прав)

возможно я )

В симфони/пхп очень распространено использование контейнера как sl в контроллерах

Но инъектить куда-то контейнер обычно плохая практика

В симфони/пхп очень распространено использование контейнера как sl в контроллерах

не дави на больное

Так это ж неплохо)

Но инъектить куда-то контейнер обычно плохая практика

так вот же в статье фаулера

это как пример SL

тут речь не о симфони и не php я могу и в java style переписать пример

Ну ты же понимаешь, что чтобы использовать SL его надо как-то получить?

И я не просто так написал обычно

это детали реализации

во времена первой зенды, когда был Zend_Registry мы вручную все сервисы регали, и потом доставали там где нужно. вот адок был)

мы сейчас говорим о sl, di, ioc

так это паттерн регистр

я просто сейчас со стороны пытаюсь понять людей

я со многими на своем опыте общался

и каждый понимал sl, di, ioc по своему

очень редко мнения сходились

причем все противоречия были именно в примерах

в обсуждение на словах все было ок)

di это внедрнеие зависимостей, все соглашаются

у тебя может быть класс сервис-локатор, тому пример getRepository метод в entity manager доктрины

а на практие говно на вентилятор

кто цитировать фаулера

кто русскую вики

кто английскую вики

кто искать статьи на хабре в подтверждение слов

кто то пытался бандой четырех объяснить

размыто только понятие ioc, остальные более чем конкретные

да нет вот даже в чате человек

объянсял сейчас мне

он в целом тоже прав

вы тут 2 часа эту тему мусолили. все не читал

ну как я теперь определю что читал что нет)

как итог никто до конца не дал определений) так на словах абстрактненько)

по IoC достаточно спросить "почему template method это тоже IoC подход?"

template method из фаулеровской статьи?

тут о template method беседы не было

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

тут о template method беседы не было

была беседа про ioc

и мы рассматривали много из подмножества ioc

потому была и про них беседа)

ERROR: S client not available

Di если что тоже не про создание объектов)

потому была и про них беседа)

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

Под паттернами обычно подразумеваются gof, иногда грасп. Думаю плохое слово для этого обсуждения

так они в этой книге и условно разделены на 3 основные группы

Behavioral - поведенческие

Creational - порождающие

ну и структурные

даже на вики также группируются

ладно настало время работать)

Под паттернами обычно подразумеваются gof, иногда грасп. Думаю плохое слово для этого обсуждения

+1

Очень хорошая заметка у дяди Боба сегодня. Помню @fes0r мне тоже самое объяснил, и это открыло глаза на многие вещи. http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html

Господи, ну как же меня достал мой немецкий CTO!

реально, какой нибудь немец встал бы и ушел. А русский ванька терпит

Указывает на vendor-ные зависмости, как будто это плохо

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

Прекрасно!

http://oauth2-client.thephpleague.com/

Зависимость от этой библиотеки - это хорошо или таки плохо?

Зависимость от этой библиотеки - это хорошо или таки плохо?

смотря где

если изолировано от бизнес логики - то норм

я имею в виду прямую зависимость (coupling)

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

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

your business logic should be decoupled from the framework, which vendors are a part of

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

ну и есть нюансы

иногда можно завязать код

ты же завязываешь код на PHP

и его стандартную библиотеку например)

чем сложнее система, тем больше надо абстрагироваться от деталей (фреймворка)

это в целом логично если с позиции декомпозиции смотреть

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