http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html в листай в конец, там блок Дополнительные ссылки и в нем три отдельных статьи по инъекциям черзе конструктор, сеттер, и свойство. Достаточно подробные.

Это вообще класс

Уговорил, подписываюсь

а на канале есть конкрусы?

@fes0r @mkusher @f3ath

Dependency injection наглядно

@f3ath

@Enleur

@oneerror

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

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

А кто мешает дёрнуть сей метод потом не прибегая к контейнеру?

Если ещё лучше: Я, как последний мудак, получил сервис из контейнера дёрнул сеттер.

ну дернул, ну и ничего страшного. Минус не в том что ты можешь его дернуть, а в том что интерфейс твоего объекта сложнее чем надо

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

Ну у меня 2 разных адаптера за интерфейсом. Конфигурил например pdo_mysql, засеттил из вне pdo_pgsql. Такое себе щасце

даже при наличии контейнера: какой смысл зависимости передавать акцессорами? какие бонусы это даёт?

даже при наличии контейнера: какой смысл зависимости передавать акцессорами? какие бонусы это даёт?

например у тебя нет возможности конструктор поправить)))

кастыли короч

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

ну блин)

но в конечном итоге они должны быть уничтожены

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

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

Да, я уже прочитал про это, спасибо

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html?m=1 В этой статье используется понятие "контейнер". Что означает термин?

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html?m=1 В этой статье используется понятие "контейнер". Что означает термин?

> Подливает масло в огонь рассогласованность использования этих терминов. Так, например, контейнеры иногда называют DI-контейнерами, а иногда IoC-контейнерами. Нет?

Нет ) тогда возникает вопрос, что такое di контейнер итд

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

Мне нравится называть его сервис контейнер

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

ты описал сервис локатор)

А дальнейшее именование это уже вопрос использования

ты описал сервис локатор)

Ну нет

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

Точнее если мы дергаем напрямую сервисы из этого контейнера то да

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

то что я написал, больше смахивает на фабрику

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html?m=1 В этой статье используется понятие "контейнер". Что означает термин?

контейнер - хрень которая что-то хранит.

IoC - принцип, DI - имплементация этого принципа (относительно управления зависимостями)

IoC контейнер - как по мне неверное использование термина IoC, DI-контейнер - непосредственно хрень которая разруливает зависимости

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

нормальные сервис локаторы обычно ограничивают к чему ты имеешь доступ. В идеале у тебя по локатору на сервис. Тогда большая часть минусов у них исчезает. Офигенно помогает когда тебе достался дикий легаси и впихнуть туда DI не выходит

У тебя отдельная графа страданий про легаси)

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

но только если эти локаторы нормальные (а не один для всего)

В большинстве случаев сервис локатор - самый тупой реестр, в котором всё свалено.

Если не во всех...

В большинстве случаев сервис локатор - самый тупой реестр, в котором всё свалено.

в большинстве случаев люди делают все через одно место. Но о чем это я?

Просто каким он должен быть, этот идеал? Именно прям отдельный сервис? Есть какой-нить сферический пример, где оно зайдёт?

Просто каким он должен быть, этот идеал? Именно прям отдельный сервис? Есть какой-нить сферический пример, где оно зайдёт?

отдельный локатор для отдельного сервиса.

у фаулера можешь глянуть)

Доберусь домой, гляну) Заодно попытаюсь в голове утрясти ценность этой идеи)

Доброй ночи, прошу помощи!) Какой патерн лучше реализовать для такой задачи - Нужно сделать интерфейс для вывода информации с разных Api, с разной структурой данных

почему вы решили, что все эти api - одна общая задача?

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

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

какие "такие"?

"Нужно сделать интерфейс для вывода информации с разных Api, с разной структурой данных"

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

"Нужно сделать интерфейс для вывода информации с разных Api, с разной структурой данных"

а интерфейс должен возвращать в одной структуре?

а интерфейс должен возвращать в одной структуре?

да

ну так все просто - одна абстракция (интерфейс) за которым инкапсулируешь все твои апи и которая будет возвращать один формат, а потом под конкретное апи делаешь реализацию

Первый мой шаг был - это сделать интерфейс, сделать несколько разных классов для разных API, ну и унаследоваться от интерфейса. Реализовал - заработало.

и потом через DI уже подкидываешь что нужно

Первый мой шаг был - это сделать интерфейс, сделать несколько разных классов для разных API, ну и унаследоваться от интерфейса. Реализовал - заработало.

может реализовать интерфейс? а не наследоваться?

может реализовать интерфейс? а не наследоваться?

Вы правы, ошибся

может реализовать интерфейс? а не наследоваться?

Ты ничего не понимаешь

Ты ничего не понимаешь

что не так

?

Все таки, ты действительно ничего не понимаешь)

ладно, я понял, пошла травля, спс за ответы

О какой травле идет речь?

О какой травле идет речь?

Ты ничего не понимаешь

Все таки, ты действительно ничего не понимаешь)

Ты че

Ты че

?

?

Все таки, ты действительно ничего не понимаешь)

По-моему вы оба ничего не понимаете

Че то уже я ничего не понимаю

адаптеры обсуждаете?

Обсуждаем кто ничего не понимает х2

адаптеры обсуждаете?

асм

накину немного - тут есть кто использует CI? Ну то есть не тулы а именно саму концепцию с ежедненой (или чаще) интеграцией?

как держать весь жизненный цикл PR в пределах суток? или забить и только с trunk based dev мы получаем настоящий CI?