В данной статье мы попытаемся разобраться с Dependency Injection в Android (и не только) на примере набирающей популярность open source библиотеки Dagger
И так, что же такое Dependency Injection? Согласно википедии, это design pattern, позволяющий динамически описывать зависимости в коде, разделяя бизнес-логику на более мелкие блоки. Это удобно в первую очередь тем, что впоследствии можно эти самые блоки подменять тестовыми, тем самым ограничивая зону тестирования.
Несмотря на замудреное определение, принцип довольно прост и тривиален. Я уверен, что большинство из программистов так или иначе реализовывали этот pattern, даже порой об этом не догадываясь.
Рассмотрим упрощенную (до псевдокода) версию Twitter клиента.
В теории, диаграмма зависимостей выглядит примерно так:
Давайте взглянем как это выглядит в коде:
public class Tweeter
{
public void tweet(String tweet)
{
TwitterApi api = new TwitterApi();
api.postTweet("Test User", tweet);
}
}
public class TwitterApi
{
public void postTweet(String user, String tweet)
{
HttpClient client = new OkHttpClient();
HttpUrlConnection connection = client.open("....");
/* post tweet */
}
}
Как видим, набор интерфейсов довольно прост, поэтому использовать мы это будем примерно так:
Tweeter tweeter = new Tweeter();
tweeter.tweet("Hello world!");
Пока все идет хорошо, твиты улетают — все счастливы. Теперь возникает необходимость все это протестировать. Сразу же замечаем, что неплохо было бы иметь возможность подменять Http клиент на тестовый, чтобы возвращать какой-нибудь тестовый результат и не ломиться в сеть каждый раз. В этом случае, нам надо снять с класса TwitterApi обязанность создавать Http клиент и сгрузить эту обязанность вышестоящим классам. Наш код немного преображается:
public class Tweeter
{
private TwitterApi api;
public Tweeter(HttpClient httpClient)
{
this.api = new TwitterApi(httpClient);
}
public void tweet(String tweet)
{
api.postTweet("Test User", tweet);
}
}
public class TwitterApi
{
private HttpClient client;
public TwitterApi(HttpClient client)
{
this.client = client;
}
public void postTweet(String user, String tweet)
{
HttpUrlConnection connection = client.open("....");
/* post tweet */
}
}
Теперь мы видим, что при необходимости простестировать наш код, мы можем легко «подставить» тестовый Http клиент, который будет возвращать тестовые результаты:
Tweeter tweeter = new Tweeter(new MockHttpClient);
tweeter.tweet("Hello world!");
Казалось бы, что может быть проще? На самом деле, сейчас мы «вручную» реализовали Dependency Injection паттерн. Но есть одно «но». Представим ситуацию, что у нас есть класс Timeline, который умеет загружать последние n сообщений. Этот класс тоже использует TwitterApi:
Timeline timeline = new Timeline(new OkHttpClient(), "Test User");
timeline.loadMore(20);
for(Tweet tweet: timeline.get())
{
System.out.println(tweet);
}
Наш класс выглядит примерно так:
public class Timeline
{
String user;
TweeterApi api;
public Timeline(HttpClient httpClient, String user)
{
this.user = user;
this.api = new TweeterApi(httpClient);
}
public void loadMore(int n){/*.....*/}
public List<Tweet> get(){/*.......*/}
}
Вроде бы все ничего — мы применили тот же подход, что и с классом Tweeter — дали возможность указывать Http клиент при создании объекта, что позволяет нам протестировать этот модуль, не завися при этом от сети. Но! Вы заметили, сколько кода мы продублировали и как нам приходится «протаскивать» Http клиент прямо из «головы» приложения? Конечно, можно добавить конструкторы по умолчанию, которые будут создавать реальный Http клиент, и использовать кастомный конструктор только при тестировании, но ведь это не решает проблему, а только маскирует ее.
Давайте рассмотрим как мы можем улучшить сложившуюся ситуацию.
Dagger
Dagger — это open source Dependency Injection библиотека от разработчиков okhttp, retrofit, picasso и многих других замечательных библиотек, известных многим Android разработчикам.
Главные преимущества Dagger (по сравнению с тем же Guice):
- Статический анализ всех зависимостей
- Определение ошибок конфигурации на этапе компиляции (не только в runtime)
- Отсутсвие reflection, что значительно ускоряет процесс конфигурации
- Довольно небольшая нагрузка на память
В Dagger процесс конфигурации зависимостей разбит на 3 больших блока:
- инициализация графа завизимостей (ObjectGraph)
- запрос зависимостей (
@Inject) - удовлетворение зависимостей (
@Model/@Provides)
Запрос зависимостей (request dependency)
Чтобы попросить Dagger проиницализировать одно из полей, все что нужно сделать — добавить аннотацию @Inject:
@Inject
private HttpClient client;
… и убедиться, что этот класс добавлен в граф зависимостей (об этом далее)
Удовлетворение зависимостей (provide dependency)
Чтобы сказать даггеру какой инстанс клиента необходимо создать, нужер создать «модуль» — класс аннотированный @Module:
@Module
public class NetworkModule{...}
Этот класс отвечает за «удовлетворение» части зависимостей, запрошенных приложением. В этом классе нужно создать так называемый «провайдер» — метод, который возвращает инстанс HttpClient (аннотированный @Provide):
@Module(injects=TwitterApi.class)
public class NetworkModule
{
@Provides @Singleton
HttpClient provideHttpClient()
{
return new OkHttpClient();
}
}
Этим мы сказали Dagger'y, чтобы он создал OkHttpClient для любого, кто попросил HttpClient посредством @Inject аннотации
Стоит упомянуть, что для того, чтобы compile-time валидация работала, необходимо указать все классы (в параметре injects), которые просят эту зависимость. В нашем случае, HttpClient необходим только TwitterApi классу.
Аннотация @Singleton указывает Dagger'у, что необходимо создать только 1 инстанс клиента и закэшировать его.
Cоздание графа
Теперь перейдем к созданию графа. Для этого я создал класс Injector, который инициализирует граф одним (или более) модулем. В контексте Android приложения, удобней всего это делать при создании приложения (наследуемся от Application и перегружаем onCreate()). В данном примере, я создал TweeterApp клас, который содержит в себе остальные компоненты (Tweeter и Timeline)
public class Injector
{
public static ObjectGraph graph;
public static void init(Object... modules)
{
graph = ObjectGraph.create(modules);
}
public static void inject(Object target)
{
graph.inject(target);
}
}
public class TweeterApp
{
public static void main(String... args)
{
Injector.init(new NetworkModule());
Tweeter tweeter = new Tweeter();
tweeter.tweet("Hello world");
Timeline timeline = new Timeline("Test User");
timeline.loadMore(20);
for(Tweet tweet: timeline.get())
{
System.out.println(tweet);
}
}
}
Теперь вернемся к запросу зависимостей:
public class TwitterApi
{
@Inject
private HttpClient client;
public TwitterApi()
{
//Добавляем класс в граф зависимостей
Injector.inject(this);
this.client = client;
}
public void postTweet(String user, String tweet)
{
HttpUrlConnection connection = client.open("....");
/* post tweet */
}
}
Заметьте Injector.inject(Object). Это необходимо для того, чтобы добавить класс в граф зависимостей. Т.е. если у нас есть хотя бы один @Inject в классе — нам необходимо добавить этот класс к граф. В результате в нашем графе должны быть все классы, которые просят зависимости (каждый из этих классов должен сделать ObjectGraph.inject()) + модули, которые удовлетворяют эти зависимости.
Теперь вернемся к нашей изначальной задаче — протестировать все. Нам необходимо каким-то образом уметь подменять HttStack. За удовлетворение этой зависимости (хмм — только сейчас заметил как это интересно звучит) отвечает модуль NetworkModule:
@Provides @Singleton
HttpClient provideHttpClient()
{
return new OkHttpClient();
}
Один из вариантов — это добавить какой-нибудь конфигурационный файл, который будет диктовать какой environment использовать:
@Provides @Singleton
HttpClient provideHttpClient()
{
if(Config.isDebugMode())
{
return new MockHttpClient();
}
return new OkHttpClient();
}
Но есть вариант еще элегантней. В Dagger можно создавать модули, переопределяющие функции, предоставляющие зависимости. Для этого в модуль надо добавить параметр overrides=true:
@Module(overrides=true, injects=TwitterApi.class)
public class MockNetworkModule
{
@Provides @Singleton
HttpClient provideHttpClient()
{
return new MockHttpClient();
}
}
Все что остается сделать — это добавить этот модуль в граф на этапе инициализации:
public class TweeterApp
{
public static void main(String... args)
{
Injector.init(new NetworkModule(), new MockNetworkModule());
Tweeter tweeter = new Tweeter();
tweeter.tweet("Hello world");
Timeline timeline = new Timeline("Test User");
timeline.loadMore(20);
for(Tweet tweet: timeline.get())
{
System.out.println(tweet);
}
}
}
Теперь все наши запросы будут идти через тестовый Http клиент.
Это далеко не все фичи Dagger'a — я описал только один из возможных сценариев использования данной библиотеки. В любом случае, без вдумчивого прочтения документации не обойтись.
Список полезных материалов по теме:
- Общее описаниe Dependency Injection
- Официальный сайт проекта
- Google Hangout видеозапись с разработчиками библиотеки
- Мой маленький пример использования библиотеки на GitHub
- Слайды с презентации Jake Wharton на Devoxx конференции (видео он пообещал выложить позже)
Автор: putchik
