Проблемы точечной застройки в больших городах или...

58
ВАМ ПРИВЕТ

Transcript of Проблемы точечной застройки в больших городах или...

ВАМ ПРИВЕТ

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

Олег Долгих,Improve Digital

О чем:

1экран

1запрос

• Немного SOLID• Модульность и уровни абстракции• Dependency Injection• Dagger 2

Хотелки

1экран

1запрос

SOLID

S Single responsibility principle (принцип единственной обязанности)

У класса должна быть всего одна причина изменяться

OOpen/closed principle(принцип открытости/закрытости)

Классы должны быть открыты для раширения, но закрыты для изменения

L Liskov substitution principle (принцип подстановки Барбары Лисков)

Наследующий класс должен дополнять, а не замещать поведение базового класса

I Interface segregation principle (принцип разделения интерфейса)

Клиенты не должны зависеть от методов, которые они не используют

D Dependency inversion principle (принцип инверсии зависимостей)

Код должен зависеть от абстракций, а не от конкретных классов

D Dependency inversion principle (принцип инверсии зависимостей)

DIP определяет отношение этих трех сущностей так:a) Клиент ничего не должен знать о реализации модуля.

Он имеет дело только с интерфейсом;b) Реализация модуля не должна знать о клиенте. Она

предоставляет функциональность и реализует определенный интерфейс;

c) Интерфейс не должен зависеть от реализации. Он вообще не должен знать о ней;

d) Реализация должна зависеть от интерфейса;

ДУЛЬМО

НОСТЬ

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

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

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

Dependency Injection

Service Locator

1. Service Locator

1. Service Locator

• Неясный контракт класса

Сервис-локатор многие считают анти-паттерном:

• Неопределенная сложность класса

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

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

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

ПРИЧЕМ ЗДЕСЬ

ТОЧЕЧНАЯ ЗАСТРОЙКА

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

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

UserManager

UserStore ApiService

UserManager

UserStore ApiService

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

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

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

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

UserManager

UserStore ApiService

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

DI ФРЕЙМВОРКИ

• Runtime валидация графа зависимостей• reflection

Dagger 2:• Никакого reflection• Compiletime валидация графа зависимостей.• Классная кодогенерация.

Guice, RoboGuice, Spring, PicoContainer …

Dagger 1:• Compile-time валидация графа зависимостей• Избавлен от кучи reflection, но по прежнему

использует ее для загрузки сгенерированных классов

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

Dagger API

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

Dagger API

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

Dagger API

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

Dagger API

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

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

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

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

Олег Долгих,Android-разработчик Improve Digital

Ресурсы:• 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