Практическое применение принципа инверсии...
-
Upload
provectus -
Category
Technology
-
view
217 -
download
4
Transcript of Практическое применение принципа инверсии...
Практическое применениепринципа инверсии зависимостей
на примере Ruby
Руслан Гатиятов // Дроид Лабсhttp://droidlabs.pro // https://planiro.com
Проблемы- сильная связанность кода (god object)- неявность кода- сложно тестировать, медленные тесты- непонятные тесты (mocks and stubs)- не применяется практика TDD- convention over configuration sucks- хуки в коде- кто должен быть тоньше? controller VS model- неудобно работать с модулями в Ruby: A::B::C::D::E.new
- не видно всех зависимостей класса (software readers, not software
writers)
SOLIDПринцип инверсии зависимостейРоберт Мартин
A. Модули высшего порядка не должны напрямую зависеть от модулей нижнего порядка. И и те и другие должны зависеть от абстракций.B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Пример без DI
Типы инъеций- инъекция через конструктор
- call-time инъекция
- инъекция через сеттеры
- Ioc Container
Инъекция через конструктор
Проблемы:
1. Добавление новых
зависимостей2. Переопределение
конструктора3. Как подменить
зависимость?
4. Цикличные зависимости5. Много зависимостей ->
много аргументов
коструктора
Call-time инъекцияПроблемы:
1. Добавление новых
зависимостей2. Переопределение
конструктора3. Как подменить зависимость?
4. Цикличные зависимости5. Много зависимостей -> много
аргументов коструктора6. Подстановка зависимостей по
умолчанию
Инъекция через сеттерыПроблемы:
1. Зависимости проставляются
вручную2. Путаница с другими
сеттерами3. Можно забыть удалить сеттер,
когда зависимость больше не
используется
Ioc Container
Проблемы:
1. Нужен агент для
инстанциирования
зависимостей2. Необходим DSL
3. Зависимости добавлять очень
просто -> God object
4. Нужно придерживаться
определенных правил
Overhead
Преимущества- видны зависимости модуля
- возможность использования различных
реализаций интерфейса
- различные конфигурации системы
- легкое тестирование
Не стоит использовать если- У всех классов всего одна реализация- Нет зависимости от конфигурации приложения- Нет опыта использования ООП
Общие рекомендации- stateless классы
- следить за числом зависимостей модуля
- value objects не должны попадать под DI
- не использовать глобальный Ioc Container
- оборачивать внешние библиотеки
- на CI только исходные реализации
Тестовая релизация
Автоматизация
Что и как тестировать?
Остановка времени
Слои приложения
DSL для тестов
Спасибо за внимание!