 |
|
|
|
Создание контейнера IoC под себя
Создание контейнера IoC под себя С темой IoC-контейнеров связано достаточно много «черной магии». На самом деле все очень просто; мы покажем это на примере создания своего IoC-контейнера. При переходе в компанию НПО «Сапфир» [1] мне пришлось столкнуться с большим объемом унаследованного кода (написанного на языке C#), при работе с которым возник ряд проблем. И одной из таких проблем была достаточно нетривиальная и запутанная инициализация приложения с использованием IoC-контейнеров из библиотеки Castle Windsor. По ходу устранения разнообразных проблем с инициализацией стало понятно, что необходимо полностью отказаться от использования библиотеки Castle Windsor. В результате поисков замены оказалось, что нет библиотек, устраивающих требованиям (по крайней мере мне не удалось найти). И тогда было принято решение написать свой собственный IoC-контейнер. Хочу рассказать, как у меня это получилось. Следует отдельно сказать: все, о чем пойдет речь в статье, относится к языку C# версии 3.0 и выше (и платформе .NET Framework версии 3.5 и выше). Что такое IoC? Прежде чем начинать что-либо делать, стоит разобраться с предметной областью; давайте и мы поступим точно так же. Первый вопрос, который стоит обсудить: что такое инверсия управления (inversion of control, IoC)? Обычно приложение состоит из небольших кирпичиков кода, взаимодействующих друг с другом. В объектно-ориентированных языках программирования эти кирпичики кода называются классами (в дальнейшем мы будем говорить в терминах классов и объектов). Вполне логично, что при этом одни классы зависят от других классов (как на уровне самих классов, так и на уровне их экземпляров – объектов). Часто эта зависимость выражается следующим образом. Допустим, что у нас есть два класса A и B. Объекты класса A зависят от объектов класса B следующим образом: при создании объекта класса A создается объект класса B, сохраняется в одном из полей объекта класса A и вдальнейшем используется объектом класса A для выполнения своей работы. При таком подходе получается, что классы A и B являются сильно связанными классами. Действительно, класс B реализует некоторую функциональность и о конкретной реализации этой функциональности знает класс A; если мы захотим изменить конкретную реализацию, используемую классом A, то нам необходимо будем изменять сам класс A. При написании тестов на класс A мы будет вынуждены тестировать при этом и класс B, что сильно усложняет написание тестов. Поэтому обычно связанность между классами снижают (бывают ситуации, когда этого делать не нужно, например, в случае вспомогательных классов). Для этого поступают следующим образом: вводят некоторый интерфейс I (или абстрактный базовый класс), одной из реализаций которого будет класс B, после чего заменяют зависимость класса A от класса B на зависимость отинтерфейса I. При такой замене класс A уже не может содержать код по созданию класса B, поэтому экземпляр реализации интерфейса I передается при создании объекта класса A в качестве одного из параметров (например, конструктора). Такой подход к организации зависимостей между классами и называется инверсией управления. Процесс передачи экземпляра реализации интерфейса I при создании объектов класса A называется внедрением зависимостей (dependency injection). И, наконец, контейнеры IoC – это компоновщики, позволяющие централизовать и автоматизировать создание компонентов (объектов) с учетом внедрения зависимостей. Статью целиком читайте в журнале «Системный администратор», №4 за 2015 г. на страницах 63-67. PDF-версию данного номера можно приобрести в нашем магазине. |
АНДРЕЙ УШАКОВ, НПО «Сапфир», ведущий разработчик/архитектор, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
