design principles
DESCRIPTION
TRANSCRIPT
Слабая связанность и критерии хорошего дизайна
Цели проектирования
Перед проектом
За день до релиза
Что пошло не так?
К чему стремимся
• Гибкость• Надежность• Компонентность• Чистый и понятный код• Визуализация
S.O.L.I.D.
Single Responsibility Principle
• Класс должен иметь лишь одну возможную причину для изменений.
Demo
• SRP violation
Open/Close Principle
• Класс открыт для расширения– новое поведение может добавиться в будущем
• Закрыт для модификации– изменения в код класса не допускаются
Demo
• OCP violation
Как это сделать?
• Параметры– лямбда/делегаты
• Наследование– дочерние классы переопределяют поведение родительского
класса
• Композиция/Strategy– передаем абстракцию– используем этот класс в существующем для реализации
расширений
Liskov Substitution Principle
• Подтипы должны быть заменяемы базовыми типами
Liskov Substition Principle
• Is – a• Is – substitutable – for
• Дочерние классы не должны нарушать поведения родительских контрактов (пред-условия и пост-условия)
Liskov Substitution Principle
• LSP violation
Liskov Substitution Principle
• Создаем новый класс– два класса делят функциональность, но не заменяемы– можно создать 3 класс от которого пронаследовать эти
два класс– Убедится что классы наследники и родитель
заменяемы
Interface Segregation Pinciple
• Принцип разделения интерфейсов– Клиенты не должны зависить от методов
которые они не используют
Interface Segregation Principle
• Лишняя абстракция в наследовании• «Жирный» интерфейс
Interface Segregation Principle
Dependency Inversion Principle
• Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции.
• Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Зависимости
• Внешние библиотеки• База данных• Статические методы• New keyword• Сетевые взаимодействия• System Clock• Random
Зависимости класса
• Конструктор класса должен указывать зависимости в которых он нуждается (явные зависимости)
• Остальные классы работают со скрытыми зависимостями
Demo
• DIP violation
Dependency Injection
• Техника когда вызывающий класс поставляет(to inject) зависимости вызываемому классу
• 3 основных способа:• Через конструктор• Через свойство• Через параметр
Constructor Injection
• За– четко выдны зависимости класса– можно работать как с контейнером так и без– класс всегда в валидном состоянии после создания
• Против– может быть много параметров в конструкторе (ds)– не всем методам нужны переданные параметры (ds)– иногда нужен конструктор без параметров
Property Injection
• За – зависимость можно передать в любой момент– очень гибко
• Против– Объект может быть в нестабильнос состоянии если какая-то
из зависимостей не передана– менее явно
Parameter Injection
• За– Не нужно менять весь класс– очень гибко
• Против– путает сигнатуру метода– много параметров (ds)
Demo
Где создавать объекты?• Конструктор по умолчанию без параметров (poor man’s ioc)• composition root• IoC container
IoC Container• Инициализируют граф объектов• Регистрируют типы объектов• Разрешают типы объектов• Можно использовать как код так и конфигурацию
Harlem Shake!