Сервис локатор – это очень неоднозначный паттерн проектирования. С одной стороны, именно с его появлением началось активное развитие DI контейнеров и практик инверсии управления. С другой стороны, именно благодаря повсеместному использованию сервис локаторов в приложениях техники управления зависимостями получили и продолжают получать столько критики.
Но прежде чем переходить к описанию достоинств и недостатков этого паттерна, давайте дадим его описание и общую структуру.
Во-первых, я внимательно подхожу к выбору книг. К сожалению (или счастью), сейчас о программировании выходят десятки книг в месяц и далеко не каждая из них достойна нашего с вами внимания. В любой области, от алгоритмов до управления проектами, есть классические книги, поэтому для начала я нахожу наиболее интересный и авторитетный источник, а не бросаюсь на первую попавшуюся мне книгу.
На примере кода Боба Мартина из его книги «Принципы, паттерны и методики гибкой разработки»
Наличие в книгах ошибок дело совсем не новое, но данный случай немного особый. Во-первых, речь идет о книге, в которой, по словам автора, "именно код и является сутью этой книги", а во-вторых, подобные ошибки являются относительно простыми и показательными, чтобы мы с вами их не допускали в своих проектах.
Описывая TDD Боб Мартин пишет о том, что TDD – это не просто вначале тесты, а потом код, это способ обдумывания дизайна класса через призму тестов, что делает его более обдуманным и слабосвязанным. Этот подход вполне оправдан и юнит тесты и правда являются отличной лакмусовой бумажкой качественного дизайна.
Обсуждая практические аспекты управления зависимостями я говорил о том, что суть инверсии зависимостей заключается в том, что мы не хотим захламлять текущий класс лишними деталями, поэтому перекладываем их на более высокий уровень.
Интуитивно понятно, что в этом случае мы не избавляемся от зависимостей, а лишь перемещаем проблему из одного места в другое. Насколько этот подход разумен? Почему зависимости в одном месте влекут к проблемам сопровождаемости, а зависимости в другом месте безвредны?
В большинстве приложений оптимизации, о которых я писал в прошлый раз, совершенно неинтересны: будет ли экземпляр делегата создаваться каждый раз или он будет создаваться лишь первый раз и сохраняться в кэше. Но в таких проектах, как РеШарпер, Visual Studio или компилятор, этому придается важное значение, поэтому не удивительно, что во многих сессиях вопросы эффективности так или иначе затрагиваются.
Я не могу сказать, что такое же внимание к эффективности требуется для “обычных” проектов, тем не менее, понимание того, что происходит за кулисами может помочь тогда, когда в этом появится необходимость. Вот на парочке подобных примеров я и хочу остановиться.
В этом году я первый раз попал на MVP Summit, который ежегодно проводит Майкрософт для своих MVP. Он длится 3 дня и многое, что на нем рассказывается попадает под NDA (Non-Disclosure Agreement) и разглашению не подлежит. Но помимо закрытой информации, тут сами MVP делятся друг с другом полезными советами, да и то, что рассказывают сотрудники МС-а довольно часто доступно публично.
Сегодня никакой особой программы не было, помимо регистрации и стартового мероприятия (знакомства всех со всеми), но для dev подразделения было сделано небольшое исключение в виде QA-сессии со Стивеном Таубом (Stephen Toub) и Lucian Wischik (даже не буду пытаться транслитить). Это была чистейшей воды ad hoc сессия на которой обсуждали практически любые вопросы, связанные с асинхронностью и не только (даже успели потролить на тему Ambient Context vs Dependency Injection).
Сегодня мы переходим к самому простому паттерну передачи зависимостей – передаче через аргументы метода, Method Injection.
Существует две разновидности паттерна под названием Method Injection. В некоторых случаях под этим паттерном понимается установка зависимостей объекта с помощью вызова метода: