Инверсия зависимостей на практике

При обсуждении прошлой заметки в Г+ был задан вопрос о том, как избежать передачи самого контейнера в конкретные классы и ограничить распространение библиотеки управления зависимостями минимальным количеством мест. Я все равно думал раскрыть эту тему, а раз так, то почему бы не сделать этого сейчас.

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

DI Паттерны. Property Injection

Возвращаемся к теме управления зависимостями, заброшенными  на некоторое время.

Еще одним достаточно популярным паттерном внедрения зависимостей является Property Injection, который заключается в передаче нужных зависимостей через “setter” свойства. Все современные DI-контейнеры в той или иной мере поддерживают этот паттерн, что делает его использование достаточно простым. Я рекомендую быть осторожным с этим паттерном, поскольку с точки дизайна передача зависимостей через свойства усложняет использование, понимание и поддержку.

Но давайте обо всем по порядку.

8 наиболее распространенных ошибок C# программистов

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

Я иногда почитываю dzone и периодически нахожу там довольно интересные статьи, и вот вчера, в разделе "Popular on DZone" наткнулся на любопытную статью под названием “8 Most common mistakes C# developers make”.

Я предлагаю вначале полистать вам ее самому, а уже потом смотреть мои комментарии.

Ретроспектива 2012

Мне очень запомнился один момент, который произошел уже без малого 10 лет назад. Я только пошел на свою первую работу и проработал там несколько месяцев; в перерыве между парами мы стояли с моим другом в коридоре и я оживленно рассказывал о чем-то, что я недавно узнал благодаря первым шагам в мире разработки ПО. Мой друг к тому времени уже проработал года полтора или два и сказал мне: «Ничего, Серега. Пройдет еще годик другой и твое отношение к этому делу изменится». С того памятного для меня разговора прошло почти десять лет, а меня так и не «попустило»; мои интересы в области программирования, меняются, но сам интерес остается неизменным.

О вреде изменяемых значимых типов. Часть 2

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

 

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

Disposable структуры

Предположим, у нас есть простенькая структура, реализующая интерфейс IDisposable:

DI Паттерны. Constructor Injection

Когда речь заходит о внедрении зависимостей (Dependency Injection), то у большинства разработчиков в голове возникает образ конструктора, через который эта зависимость передается в виде интерфейса или абстрактного класса. Именно об этом виде управления зависимостей писал Боб Мартин в своей статье Dependency Inversion Principle, поэтому не удивительно, что он является самым известным.

Описание

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

Наследование vs Композиция vs Агрегация

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

Рисунок 1. Отношение ассоциации