Не так давно появился сайт Symfony Components, на который авторы фреймверка symfony выкладывают библиотеки, которые написаны в процессе разработки фреймверка, но могут быть использованы отдельно.

Один из таких компонентов -- Symfony Service Container.
Это компонент, который реализует паттерн Контейнер Внедрения Зависимостей.
Также была написана небольшая книга, которая описывает принципы работы компонента.

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

Мой вариант превода книги: http://madbee.ukr.su/solenko/dependency-injection/

ksnk и Sanchezzz - очень рекомендую для прочтения (после тем о загрузке классов).

Буду благодарен за критику перевода -- как-никак первый опыт.

solenko, Там есть орфографических ошибок. Можно внедрить систему орфус и корректировать прямо по прочтении...

А вообще - спасибо! Не  дочитал, но пока - интересно 

Паттерн, вообще говоря, требует перепроектирование уже спроектированной системы :-( 

К примеру, разнообразные плагины CMS'ки в редкие моменты своего функционирования желают воспользоватся функцией mail. Мы, как умные ООП программисты обернули mail в показавшуюся нам удобной в тот момент обертку.
Строки, работающие с классом выглядят как 


В дальнейшей жизни нам показалось недостаточной реализация mail и родилась обертка mail2.
Рассматриваются варианты внедрения новой обертки в уже существующие тексты плагинов с минимальной правкой исходного кода...

Рассматриваемый паттерн предлагает нам подставлять уже проинициализированный элемент класса mail2 в объект, не взирая на то, что этот класс реально может и не понадобится? Это ли тру ООП?

Это сообщение отредактировал(а) ksnk - 16.7.2009, 18:31

в статье Контейнеры Внедрения Зависимостей автор путает паттерн фабрика с паттерном "Внедрения зависимостей"  

Вообще, это паттерн-ориентированное программирование - тупик. Нужно сначала писать код, а потом уже угадывать в его контурах тот или иной паттерн   

Заивисимость != может использовать. Т.е. если ваш класс не может работать без какого-либо другого, то имеет смысл использовать внедрение зависимости. В вашем же случае -- нет.



Похоже вы путаете то, что автор называет Dependency Injection и Dependency Injection Container. Непосредственно внедрению зависимостей посвящена только первая глава.

Паттерн фабрика предназначен не для разрешения проблеммы зависимостей. Фабрика просто создает какой-либо из подтипов (наследников) более общего типа. При этом ничего не зная о том как его инициализировать и о его зависимостях.

в статье - это чистой воды фабрика. объект пользователь спрашивает у объекта фабрики - "Дай мне экземпляр объекта mail"... То что этот вопрос формулируется в виде вызова функции контейнера никак не влияет на фабричность...  Описывемый в первой главе паттерн - это да, это Dependency Injection. А остальное к нему имеет не очень большое отношение. 
Польза Dependency Injection в том, что есть единственное место (сонфигурационный файл), в котором в экземпляр - контейнер  вставляют необходимые ему для работы уже проинициированные компоненты. 
А естл эти компоненты сокрыты в непонятно где лежащем отдельном объекте контейнер, "инициализация" которого делается типично фабричным методом, то и называть такой контейнер стоит фабрикой...

Вот только не просто создается объект mail (фабрика), а еще и выполняется его конфигурирование -- создается объект mail_transport (контейнер).

Основная разница как раз в том, что фабрика подразумевает самоконфигурирование объектов, а контейнер -- конфигурирует их.

Добавлено через 2 минуты и 28 секунд
Кроме того, фабрика порождает объекты какого-либо одного класса (т.е. возвращает экземпляры подклассов одного класса), а контейнер работает с произвольными классами. Хотя ключевая разница -- конфигурирование.

Добавлено через 5 минут и 1 секунду
Кстати, перефодом я занялся после прочтения http://habrahabr.ru/blogs/php/64061/
Там рассматривается разница фабрики и контейнера.

и какой смысл "потом" в паттернах? Это какое-то антипаттерн-ориентированное программирование ;)

youri, Ну дык откуда взялись-то паттерны? Просто их "отцы-создатели" анализировали большое количество кода и обнаружили, что приемы программирования, вообще говоря можно классифицировать. Примерно та-же фигня, как и в биологии. Типо - хордовые, покрытосемменные, парнокопытные... Сильно обрадовались биологи и начали все обзывать по новой классификации, ан не тут-то было. природа она завсегда всякой классификации найдет свое исключение...  


"Здравый смысл"-ориентированное программирование!  


Да ну? Вот квинтэссенция статьи "Контейнеры Внедрения Зависимостей". Тру-ООП код, размещенный предпоследним (последний пример - несущественная для ООП мутация в сторону синглтона)

Чем, скажите мне, этот код не фабрика? "Фабричный класс" имеет четко определенный (пустой) конструктор. Сам конструктор обязан инициализироваться, выковыривая из некоей "регистри" собственные параметры. Чужой дядя, обращается к контейнеру со словами "getMailer" - дай мне почтальона... Причем тут еще какой-то Dependency Injection? Тем что этот код мутациями и издевательствами из него трансформировали?

Добавлено через 12 минут и 23 секунды
А в статейке-затравке мне понравился вот такой код-конфигурация:

 Есть в этом некая благородная креза! Хотя обильное повторение некоторых слов портит все впечатление... А вот если переписать этого монстра с помощью ассоциированного массива, может получится радующая мой глаз конструкция



Это сообщение отредактировал(а) ksnk - 16.7.2009, 22:48

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

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

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


я просто не понимаю, зачем после написания кода угадывать в нем какие-то паттерны. И для чего тогда паттерны вообще?

Вот у меня в разработке есть такой этап как перепроектирование на ходу ;-) если проект живет достаточно долго, для него, imho, в обязательном порядке наступит такой этап. Продуманная изначально архитектура позволит пережить этот этап с допустимыми потерями.

А вообще, раз и навсегда спроектированные приложения, это такая-же абстракция как и чистые, незамутненные паттерны и сферические кони. Они никому не нужны, так как не существуют в природе.

А паттерны нужны для анализа получившегося кода на этапе "доводка напильником после проектирования". Паттерны - достаточно удачные решения в каких-то ситуациях. Их нужно знать Можно "поугадывать контуры" в реальных монстрах и, если это принесет пользу, "откорректировать мутацию"...

а где я говорил, про навсегда спроектированные приложения? Ведь придумали же такую штуку как проектирование... навреное не просто так... или ты думаешь, что думать перед тем как что-то делать - абсолютно бессмысленное занятие?

solenko, спасибо. Пока что бегло просмотрел. Чуть позже прочту полностью.