Расскажу про то, каким образом связаны «страшные» буквы DI и MVP, при чём тут различные тесты и зачем всё это нужно разработчику для Android.

1. ВАМ ПРИВЕТ

2. ЗАЧЕМ НАМ DAGGER
или проблемы с точечной застройкой в больших городах
Олег Долгих,
Improve Digital

3. О чем:
1
экран
1
запрос
• Немного SOLID
• Модульность и уровни абстракции
• Dependency Injection
• Dagger 2

4. Хотелки
1
экран
1
запрос

5. SOLID

6. SSingle responsibility principle
(принцип единственной
обязанности)
У класса должна быть всего
одна причина изменяться

8. OOpen/closed principle
(принцип открытости/
закрытости)
Классы должны быть
открыты для раширения, но
закрыты для изменения

10. L Liskov substitution principle
(принцип подстановки
Барбары Лисков)
Наследующий класс должен
дополнять, а не замещать
поведение базового класса

12. I Interface segregation principle
(принцип разделения
интерфейса)
Клиенты не должны зависеть
от методов, которые они не
используют

14. DDependency inversion principle
(принцип инверсии
зависимостей)
Код должен зависеть от
абстракций, а не от
конкретных классов

15. DDependency inversion principle
(принцип инверсии
зависимостей)
DIP определяет отношение этих трех сущностей так:
a) Клиент ничего не должен знать о реализации модуля.
Он имеет дело только с интерфейсом;
b) Реализация модуля не должна знать о клиенте. Она
предоставляет функциональность и реализует
определенный интерфейс;
c) Интерфейс не должен зависеть от реализации. Он
вообще не должен знать о ней;
d) Реализация должна зависеть от интерфейса;

17. ДУЛЬ
МО
НОСТЬ

19. Как хотели: Как получилось:

20. Проблема доступа к модулям:
При вызове конструктора получится, что
модуль зависит от конкретного места его
применения.
Если в коде используются
многочисленные конкретные классы, его
придется изменять с добавлением новых
конкретных классов.

21. Dependency Injection
Service Locator

22. 1. Service Locator

23. 1. Service Locator
• Неясный контракт класса
Сервис-локатор многие считают анти-паттерном:
• Неопределенная сложность класса

24. 2. Использовать механизм Dependency injection
Три пути, которыми мы можем доставить классу
нужные параметры:
1) Constructor Injection (инъекция в конструктор)

25. 2. Использовать механизм dependency injection
Три пути, которыми мы можем доставить классу
нужные параметры:
2) Field Injection (инъекция в поле)

26. 2. Использовать механизм dependency injection
Три пути, которыми мы можем доставить классу
нужные параметры:
3) Method Injection (инъекция в метод)

27. ПРИЧЕМ
ЗДЕСЬ
ТОЧЕЧНАЯ
ЗАСТРОЙКА

28. Как хотели: Как получилось:

29. Хочу здесь детский
садик!

30. UserManager
UserStore ApiService

31. UserManager
UserStore ApiService

32. Модуль с детским
садиком перемещаем
по любому адресу

33. Меняем код с использованием паттерна Constructor
Injection, и передадим зависимости в UserManager в
качестве параметров

34. Меняем код с использованием паттерна Constructor
Injection, и передадим зависимости в UserManager в
качестве параметров

35. Наш UserManager
больше не зависит от
реализаций ApiService и
UserStore
UserManager
UserStore ApiService

36. Мы просто можем «замокать» реализации ApiService
и UserStore. UserStore теперь полностью независим.

38. DI
ФРЕЙМВОРКИ

39. • Runtime валидация графа зависимостей
• reflection
Dagger 2:
• Никакого reflection
• Compiletime валидация графа зависимостей.
• Классная кодогенерация.
Guice, RoboGuice, Spring, PicoContainer …
Dagger 1:
• Compile-time валидация графа зависимостей
• Избавлен от кучи reflection, но по прежнему
использует ее для загрузки сгенерированных классов

40. Новый взгляд на LoginActivity

41. Dagger API
@Module
@Provides
@Scope
Определяем методы
которые будут
предоставлять
зависимости в классе с
аннотацией @Module и
аннотируем их
@Provides. Если хотим
ограничить область
видимости – помечаем
аннотацией @Scope

42. Dagger API
@Component
@Subcomponent — мост
между модулями и
клиентами зависимостей.
Определяет какие модули
будут предоставлять
зависимости. Указываем
куда хотим инжектить
и/или геттер, который
вернет зависимость.

43. Dagger API
@Inject — пометить Конструктор, Поле, Метод для инъекции

44. Dagger API
@MapKey — определить коллекцию
зависимостей
@Qualifier — тегируем зависимости,
которые имеют один и тот же
интерфейс.
@Lazy — ленивая инициализация
зависимости.

55. Итого:
• Не забывайте про SOLID принципы
• Пишите модульный код
• Не переабстрагируйтесь
• Предпочитайте DI сервис локатору
• DI framework в android – Dagger 2

56. Минусы
• Повышается порог вхождения

57. Спасибо за внимание
Если у вас возникли вопросы, я с удовольствием
обсужу их с вами.
Олег Долгих,
Android-разработчик Improve Digital

58. Ресурсы:
• https://blog.gouline.net/2015/05/04/dagger-2-even-sharper-less-square/
• https://github.com/codepath/android_guides/wiki/Dependency-Injection-with-Dagger-2
• http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/
• http://sergeyteplyakov.blogspot.ru/2013/03/di-service-locator.html
• http://sergeyteplyakov.blogspot.ru/2012/12/di-constructor-injection.html
• http://sergeyteplyakov.blogspot.ru/2013/01/di-property-injection.html
• http://sergeyteplyakov.blogspot.ru/2013/02/di-method-injection.html
• https://events.yandex.ru/lib/talks/3109/
• https://www.youtube.com/watch?v=3Fn4vb1wBIs