php паттерн инъекция зависимостей

Dependency Injection (Внедрение зависимостей)

Глубокое понимание патерна «dependency injection» — очень важная вещь для крутого разработчика.

Проблема

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

Почему жесткая зависимость — это плохо? Потому что мы не можем изменить логику без изменения этих классов. Если я хочу изменить хранилище записей журнала, мне нужно изменить оба класса.

Как сделать наш пример более гибким? Конечно, используйте шаблон проектирования внедрения зависимостей.

Встречайте Dependency Injection

Больше и больше зависимостей

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

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

Dependency Injection Container

Надеюсь, вы уже знаете об автозагрузке ваших классов и файлов, потому что это первое, что нужно сделать, чтобы начать использовать Dependency Injection Container (контейнер внедрения зависимостей, DIC).

А как загрузить DIC?

Inversion Of Control

Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Также архитектурное решение интеграции, упрощающее расширение возможностей системы, при котором поток управления программы контролируется фреймворком.

Эта черная магия помогает вообще забыть о new instances в работе. Просто создайте новый файл и опишите конструктор с подсказкой типа. Контейнер внедрения зависимостей разрешает все зависимости, а не когда вы пытаетесь получить объект из контейнера.

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

Зависимости и интерфейсы

Как управлять зависимостями, если вы используете интерфейс? Создадим интерфейс ILogger :

И переименуем Logger в DBLogger :

И изменим конструктор класса OrderProcessing :

А что происходит? DIC не может решить ваши проблемы. Почему? Потому что вам нужно точно описать класс, который вы хотите использовать в этом классе. Итак, вам нужно решить эту проблему вручную:

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

Заключение

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

Источник

Что такое внедрение зависимостей в PHP

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

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

Перед тем как двигаться дальше, давайте рассмотрим более реалистичный пример. Как-то я уже писал как создать социальную сеть, а в социальных сетях крайне популярно обмениваться контентом (новости, фото, видео). Так вот, представьте, что у нас есть класс под названием SocialFeeds, который собирает новости из различных источников, таких как ВКонтакте, Twitter, Facebook и т. д. Для каждого из этих источников есть свой отдельный класс сервиса. Мы рассмотрим класс TwitterService.

Класс SocialFeeds отправляет запрос на Twitter при помощи класса TwitterService. Этот класс, в свою очередь, извлекает из базы данных специальный токен (ключ) пользователя для доступа к API Twitter. Токен передается классу OAuth, который, используя полученый ключ, запрашивает новости из Twitter и возвращает их обратно в класс SocialFeeds.

class DB
<
public function makeQuery() <
// Возвращает токен из базы данных
>
>

Здесь класс SocialFeeds зависит от класса TwitterService, который, в свою очередь, зависит от классов DB и OAuth, таким образом, и класс SocialFeeds косвенно зависит от классов DB и OAuth.

Так в чем же проблема? А проблема в том, что класс SocialFeeds зависит от конкретной реализации этих трех классов, делая невозможным, например, тестирование класса SocialFeeds как отдельную единицу. К тому же, если нам нужно будет использовать другую базу данных или провайдера OAuth, то придется искать и менять эти классы по всему коду, в котором они встречаются.

Вот здесь и становится очевидным необходимость использования механизма внедрения зависимостей (Dependency Injection, DI) в PHP. C помощью него, мы можем создавать объекты динамически, только тогда, когда это необходимо. Существуют две техники реализации этого механизма:

1) Инъекция зависимостей посредством конструктора класса. В этом приеме, зависимости объекта создаются извне и передаются конструктору класса в качестве параметра. Вот код:

Экземпляр класса TwitterService передается в качестве параметра в конструктор SocialFeeds. Несмотря на то, что класс SocialFeeds все еще зависит от сервиса TwitterService, теперь у нас есть больше свободы при выборе различных версий провайдера новостей Twitter. Подобное действие применяем и к классам DB и OAuth:

2) Инъекция зависимостей через set-метод:

// создаем объекты
$db = new DB();
$oauth = new OAuth();
$twSrv = new TwitterService();
$sf = new SocialFeeds();

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

Таким образом, сегодня мы познакомились с тем, что такое Dependency Injection (DI) в PHP и узнали, когда его следует использовать.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Комментарии ( 0 ):

Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.

Источник

Кратко о внедрение зависимостей и сервис контейнере

Dependency Injection – это программный шаблон, который реализует принцип объектно-ориентированного программирования «Инверсия управления (Inversion Of Control)». Реализация этого шаблона подразумевает снижения «связанности кода», соответственно, получается код, который легче использовать повторно и сопровождать, то есть, изменение компонент одной части приложения не вызывает ошибок в другой части или необходимости значительных каскадных изменений.

DI существет только в объектно-ориентированном мире. Рассмотрение будет проведено на примере языка PHP. Допустим, мы пишем приложение, логику мы помещаем в класс App. Наше приложение использует сторонние данные, логику получение данных помещаем в класс Service. Получается класс App зависит от класса Service. Как это реализуется? Например так:

Можно определить где-то хранилище настроек, или объявить константу за пределами класса App, или добавить ключ как параметр конструктора App.

И вот на сцену выходит внедрение зависимостей. Вместо того, чтобы создавать Service объект внутри App класса, надо создать Service заранее и затем передать его в объект App как аргумент конструктора.

Всё. В этом вся суть внедрения зависимостей. Теперь можно настраивать сервис независимо от приложения, и легко подменить класс сервиса для тестирования.

Как правило, внедрение через конструктор, как в нашем примере – это лучший способ для подключения основных зависимостей, а вот внедрение через setter – для добавления дополнительных зависимостей, например таких, как кэш.

Большинство современных PHP фреймворков активно используют внедрение зависимостей.

В простейшем случае использовать класс контейнера достаточно просто:

В случае чуть сложнее мы сделаем контейнер настраиваемым, пробросив параметры option1 и option2 через конструктор контейнера.

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

Автоматическое внедрение зависимостей

Источник

Dependency injection

От переводчика

Представляемый вашему вниманию перевод открывает серию статей от Jakob Jenkov, посвященных внедрению зависимостей, или DI. Примечательна серия тем, что в ней автор, анализируя понятия и практическое применение таких понятий как «зависимость», «внедрение зависимостей», «контейнер для внедрения зависимостей», сравнивая паттерны создания объектов, анализируя недостатки конкретных реализаций DI-контейнеров (например, Spring), рассказывает, как пришел к написанию собственного DI-контейнера. Таким образом, читателю предлагается познакомиться с довольно цельным взглядом на вопрос управления зависимостями в приложениях.

В данной статье сравнивается подход к настройке объектов изнутри и извне (DI). По смыслу настоящая статья продолжает статью Jakob Jenkov Understanding Dependencies, в которой дается определение самому понятию «зависимости» и их типам.

Серия включает в себя следующие статьи

Внедрение зависимостей

«Внедрение зависимостей» — это выражение, впервые использованное в статье Мартина Фаулера Inversion of Control Containers and the Dependency Injection Pattern. Это хорошая статья, но она упускает из виду некоторые преимущества контейнеров внедрения зависимостей. Также я не согласен с выводами статьи, но об этом — в следующих текстах.

Объяснение внедрения зависимостей

Внедрение зависимостей — это стиль настройки объекта, при котором поля объекта задаются внешней сущностью. Другими словами, объекты настраиваются внешними объектами. DI — это альтернатива самонастройке объектов. Это может выглядеть несколько абстрактно, так что посмотрим пример:

UPD: после обсуждения представленных автором фрагментов кода с flatscode и fogone, я принял решение скорректировать спорные моменты в коде. Изначальный замысел был в том, чтобы не трогать код и давать его таким, каков он написан автором. Оригинальный авторский код в спорных местах закомментирован с указанием «в оригинале», ниже дается его исправленная версия. Также оригинальный код можно найти по ссылке в начале статьи.

Этот DAO (Data Access Object), MyDao нуждается в экземпляре javax.sql.DataSource для того, чтобы получить подключения к базе данных. Подключения к БД используются для чтения и записи в БД, например, объектов Person.

Заметьте, что класс MyDao создает экземпляр DataSourceImpl, так как нуждается в источнике данных. Тот факт, что MyDao нуждается в реализации DataSource, означает, что он зависит от него. Он не может выполнить свою работу без реализации DataSource. Следовательно, MyDao имеет «зависимость» от интерфейса DataSource и от какой-то его реализации.

Класс MyDao создает экземпляр DataSourceImpl как реализацию DataSource. Следовательно, класс MyDao сам «разрешает свои зависимости». Когда класс разрешает собственные зависимости, он автоматически также зависит от классов, для которых он разрешает зависимости. В данном случае MyDao завсист также от DataSourceImpl и от четырех жестко заданных строковых значений, передаваемых в конструктор DataSourceImpl. Вы не можете ни использовать другие значения для этих четырех строк, ни использовать другую реализацию интерфейса DataSource без изменения кода.

Как вы можете видеть, в том случае, когда класс разрешает собственные зависимости, он становится негибким в отношении к этим зависимостям. Это плохо. Это значит, что если вам нужно поменять зависимости, вам нужно поменять код. В данном примере это означает, что если вам нужно использовать другую базу данных, вам потребуется поменять класс MyDao. Если у вас много DAO-классов, реализованных таким образом, вам придется изменять их все. В добавок, вы не можете провести юнит-тестирование MyDao, замокав реализацию DataSource. Вы можете использовать только DataSourceImpl. Не требуется много ума, чтобы понять, что это плохая идея.

Давайте немного поменяем дизайн:

Заметьте, что создание экземпляра DataSourceImpl перемещено в конструктор. Конструктор принимает четыре параметра, это — четыре значения, необходимые для DataSourceImpl. Хотя класс MyDao все еще зависит от этих четырех значений, он больше не разрешает зависимости сам. Они предоставляются классом, создающим экземпляр MyDao. Зависимости «внедряются» в конструктор MyDao. Отсюда и термин «внедрение (прим. перев.: или иначе — инъекция) зависимостей». Теперь возможно сменить драйвер БД, URL, имя пользователя или пароль, используемый классом MyDao без его изменения.

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

Класс MyDao может быть более независимым. Сейчас он все еще зависит и от интерфейса DataSource, и от класса DataSourceImpl. Нет необходимости зависеть от чего-то, кроме интерфейса DataSource. Это может быть достигнуто инъекцией DataSource в конструктор вместо четырех параметров строкового типа. Вот как это выглядит:

Теперь класс MyDao больше не зависит от класса DataSourceImpl или от четырех строк, необходимых конструктору DataSourceImpl. Теперь можно использовать любую реализацию DataSource в конструкторе MyDao.

Цепное внедрение зависимостей

Пример из предыдущего раздела немного упрощен. Вы можете возразить, что зависимость теперь перемещена из класса MyDao к каждому клиенту, который использует класс MyDao. Клиентам теперь приходится знать о реализации DataSource, чтобы быть в состоянии поместить его в конструктор MyDao. Вот пример:

Как вы можете видеть, теперь MyBizComponent зависит от класса DataSourceImpl и четырех строк, необходимых его конструктору. Это еще хуже, чем зависимость MyDao от них, потому что MyBizComponent теперь зависит от классов и от информации, которую он сам даже не использует. Более того, реализация DataSourceImpl и параметры конструктора принадлежат к разным слоям абстракции. Слой ниже MyBizComponent — это слой DAO.

Решение — продолжить внедрение зависимости по всем слоям. MyBizComponent должен зависеть только от экземпляра MyDao. Вот как это выглядит:

Снова зависимость, MyDao, предоставляется через конструктор. Теперь MyBizComponent зависит только от класса MyDao. Если бы MyDao был интерфейсом, можно было бы менять реализацию без ведома MyBizComponent.

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

Источник

Phemto и Паттерн Dependency Injection. Часть 1

Я не встречал хорошего описания паттерна Dependency Injection применительно к PHP.

Недавно ребята из Symfony выпустили свой контейнер DI, снабдив его подробной и хорошей книжкой о том как работать с этим паттерном.

Я вспомнил еще об одной библиотеке для DI, Phemto. Ее автор, — Маркус Бэйкер, создатель SimpleTest. К сожалению на сайте содержится краткая и невнятная справка. тем не менее, проект развиавется, а внутри дистрибутива лежит статья с крайне хорошим объяснением про DI, ну и руководством конечно. Phemto, — очень миниатюрный проект, состоящий из трех не очень больших файлов.

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

На программистском жаргоне, Phemto – это легкий, автоматизированный контейнер dependency injection (управления зависимостями). Проще говоря, задача Phemto – создавать экземпляр объекта, получая минимум информации, таким образом, значительно ослабляя зависимости внутри приложения или фреймворка.

Проще всего понять паттерн DI это представить себе шкалу с «Используем DI» на одном конце и «Используем хардкодинг (т.е. жестко запрограммированные связи)» на другом. Мы с вами сейчас устроим маленькое путешествие от хардкодинга через паттерны Factory, Registry, Service Locator к DI. Если Вы и так знаете, что такое DI, переходите сразу к
установке Phemto.

Заурядное создание объектов с помощью оператора new выглядит простым и понятным, но мы, скорее всего, столкнемся с трудностями, когда захотим что-то поменять потом. Посмотрим на код…

class MyController <
function __construct ( ) <
.
$connection = new MysqlConnection ( ) ;
>
>

Здесь MyController зависит от MysqlConnection.

Оператор new ясен и понятен, но MyController сможет использовать только БД MySQL. Немного переделать класс, чтобы было можно его наследовать едва ли поможет, т.к. тогда мы будем иметь в наследнике вместе с логикой дочернего контроллера и логику получения драйвера БД. В любом случае множественные зависимости не решаются наследованием, приводя к захламлению класса. Вообще говоря, Вы можете разыграть карту наследования только однажды.

Следующий шаг, – используем Factory…

Очень эффективное решение. Фабрика может быть настроена на нужный тип драйвера с помощью конфигурационного файла или явно. Фабрики часто могут создавать объекты из разных семейств объектов, и тогда их называют Abstract Factory (Абстрактная Фаброика) или Repository (Репозиторий). Однако тут есть ограничения.

Фабрики приносят много дополнительного кода. Если надо тестировать классы с помощью mock-объектов, то придется имитировать не только сами, возвращаемые фабрикой объекты, но и саму фабрику. Получаете немного дополнительной суеты.

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

Следующий ход в нашей борьбе с зависимостями, это вообще вынуть создание объекта Registry из основного объекта наружу…

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

Кроме того, с помощью такого подхода мы не сможем использовать ленивое создание объектов (lazy loading). Неудача ждет нас, и если мы захотим, чтобы нам возвращался не один и тот же объект адаптера к БД, а разные объекты.

Жизнь сразу ухудшится, если в нашем примере будут еще зависимости, которые надо учесть. Т.е. если, например, для создания объекта-адаптера недостаточно сделать new, а нужно добавить в конструктор какой-то еще объект. В общем, предварительная настройка грозит сделаться весьма запутанной.

Мы можем сделать паттерн Registry более изощренным, если позволим объекту Registry самостоятельно создавать экземпляры нужных объектов. Наш объект стал Сервис-локатором (Service Locator)…

Теперь настройки, могут быть в любом порядке, однако ServiceLocator должен знать, как создать MysqlConnection. Задача решается с помощью фабрик или с помощью трюков с рефлексией, хотя передача параметров, может стать весьма кропотливой работой. Жизненный цикл объектов (напр. возвращать один и тот же объект, или создавать разные) теперь под контролем программиста, который может как, запрограммировать все в методах фабрики, так и вынести все в настройки или плагины.

К сожалению, эта почти серебряная пуля имеет ту же проблему, что и Registry. Любой класс, который будет пользоваться таким интерфейсом, неизбежно будет зависеть от Сервис-локатора. Если Вы попробуете смешать две системы с разными сервис-локаторами, вы почувствуете что такое «не повезло».

Dependency Injection заходит немного с другой стороны. Посмотрим на наш самый первый пример…

class MyController <
function __construct ( ) <
.
$connection = new MysqlConnection ( ) ;
>
>

… и сделаем зависимость внешней.

На первый взгляд, это просто ужасно. Теперь ведь каждый раз в скрипте придется все эти зависимости руками трогать. Изменить адаптер к БД придется вносить изменения в сотне мест. Так бы оно и было, если бы мы использовали new…

Хотите верьте, хотите нет, но это все, что нам нужно.

Задача Phemto – выявление того, как создать объект, что позволяет на удивление здорово автоматизировать разработку. Только по типу параметра в интерфейсе он выведет, что MysqlConnection – единственный кандидат, удовлетворяющий нужному типу Connection.

Более сложные ситуации, могут потребовать дополнительной информации, которая обычно содержится в «цепочечном» файле. Вот пример такого файла из реальной жизни, чтобы можно было почувствовать мощь паттерна…

Такое количество настроек типично для проекта среднего размера.

Теперь контроллер задает только интерфейс, а работа по созданию объектов выполняется посредником.
MyController теперь не должен вообще знать про MysqlConnection.
Зато $injector знает и о том и о другом. Это называется обращение контроля Inversion of Control.

Источник