Практическое применениепринципа инверсии зависимостей

на примере 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 для тестов

Спасибо за внимание!