15 марта 2011 г.

Инъекция зависимости, инверсия контроля, xp party в Самаре

Совсем недавно отошёл от минувшей xp.party в Самаре. Это классное место, где собираются программисты из разных технологий, разных сфер разработки и совмещают применение на практике методик экстремального программирования (agile, scrum, TDD, pair-programming etc.) для изучения методологии с интересным общением и обсуждением почерпнутого как в ходе мероприятия, так и в повседневной работе.
Специально для мероприятия я готовил доклад на тему: «Инъекция зависимости, Google Guice».
Инъекция зависимости и Инверсия Контроля
View more presentations from Владимир Игнатьев.

Что такое Инъекция зависимости (Dependency Injection)?
Это всего лишь паттерн проектирования, позволяющий снять ответственность за зависимости класса с него самого. Зависимостями в общем случае являются аггрегированные и композированные классы и объекты. А реализуется этот паттерн в общем случае посредством выноса создания зависимостей в отдельный класс и передачей сформированных зависимостей в конструктор, причем прототип конструктора содержит только интерфейсы классов-зависимостей. // Это проще понять по слайдам
Этот паттерн используют там, где необходимо, к примеру, подменять реализации тех или иных составных частей класса. Простой пример - использование mock'ов и заглушек вместо реальных классов в компонентах, осуществляющих транзакции через платежные системы, чтобы при тестовой конфигурации приложения случайно не расплатиться за ошибки программистов реальными деньгами :-)

Что такое Инверсия Контроля (IoC)? Что такое IoC-контейнер?
Инверсия контроля в контексте Dependency Injection означает эффект того, что класс больше не отвечает за свои зависимости.
Более того, этот термин часто связан с термином IoC-контейнер. IoC-контейнер это такой класс, который содержит описание связей классов и инъекторы, т.е. объекты, которые непосредственно осуществляют подстановку зависимостей в классы.
В силу того, что часто карту зависимостей хранят не в коде, а в XML-файле, который используется IoC-фреймворком для формирования зависимостей, получается такой эффект, что «данные управляют кодом». Иначе говоря, различные конфигурации приложения собираются вне кода приложения. Это позволяет писать код приложения не зависящим от конкретных конфигураций и улучшить покрытие кода тестами, а также получить менее связываемую архитектуру и легко переносимый код.

Что такое аспектно-ориентированное программирование?
Аспектно-ориентированное программирование (АОП) — это парадигма программирования, косвенно связанная  с использованием DI/IoC. АОП говорит нам о том, что функциональность приложения должна быть разделена на сущности, называемые аспектами. Примерами аспектов являются:
  • кеширование
  • логирование
  • поддержка транзакций
  • авторизация
  • фильтрация данных и т.д.
Такой подход позволяет извлечь из кода блоки, которые напрямую не связаны с реализацией бизнес-логики в отдельное место.
АОП также связывают часто с контрактным программированием. Простой пример разработки, основанной на "контрактах", это когда некоторый класс-вебсервис, работает с полученными данными так, как если бы они были отфильтрованы от нежелательного ввода. Сам же код, реализующий эту фильтрацию находится вне этого веб-сервиса. Таким образом, считается что между этими двумя компонентами [фильтрация и бизнес-логика веб-сервиса] осуществляется контракт, предусловиям которого является фильтрация необходимых полей от некорректного ввода.

Использование Посредника (Mediator) в event-driven архитектурах
В презентации частично был затронут и этот вопрос. Например, во Flex и HTML/Javascript существует иерархия графических объектов, которые умеют как принимать события, так и посылать их во вне, в иерархию. События обладают bubbling'ом, т.е. объект-инициатор создаёт событие, которое может быть получено всеми вышестоящими объектами.
Фактически, такой подход позволяет создавать уединенные компоненты пользовательского интерфейса, которые могут быть связаны через глобальный диспетчер событий, выступающий фактически в роли посредника между компонентами. 
Несмотря на то, что такой подход используется в основном для UI, глобальный диспетчер-посредник или "общую шину" используют все известные фреймворки на Flex, как и например Mate Framework. 
Этот подход удобен для создания слабосвязанной архитектуры, для чего применяется и DI/IoC, и в небольших проектах может выступать даже альтернативой DI/IoC, особенно если бизнес-логику удаётся локализовать в одном контроллере. Однако, в более-менее серьёзных приложениях, где контроллеры представляют собой некоторый «слой» всё же лучше подойдёт DI/IoC.

Фреймворки Dependency Injection (DI)  для ActionScript/Flex
Mate - красивый с IoC-контейнером, Swiz - простой, Parsley - разносторонний и большой!


Фреймворки Dependency Injection (DI)  для Java
Гигант Spring Framework, прекрасная кроха Google Guice

Фреймворки Dependency Injection (DI)  для PHP

Фреймворки Dependency Injection (DI)  для Python
Отправить комментарий