SlideShare uma empresa Scribd logo
1 de 33
Слабая связанность и критерии
     хорошего дизайна
Цели проектирования
Перед проектом
За день до релиза
Что пошло не так?
К чему стремимся
•   Гибкость
•   Надежность
•   Компонентность
•   Чистый и понятный код
•   Визуализация
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!

Mais conteúdo relacionado

Mais procurados

Web driver история одной миграции
Web driver   история одной миграцииWeb driver   история одной миграции
Web driver история одной миграции
Igor Khrol
 
Тестирование весна 2014 смешанное занятие 2
Тестирование весна 2014 смешанное занятие 2Тестирование весна 2014 смешанное занятие 2
Тестирование весна 2014 смешанное занятие 2
Technopark
 
Майстер-клас "Автоматизоване тестування. З чого почати?
Майстер-клас "Автоматизоване тестування. З чого почати?Майстер-клас "Автоматизоване тестування. З чого почати?
Майстер-клас "Автоматизоване тестування. З чого почати?
DataArt
 
Cовременный контроль качества: давай сделаем это по-быстрому...
Cовременный контроль качества: давай сделаем это по-быстрому...Cовременный контроль качества: давай сделаем это по-быстрому...
Cовременный контроль качества: давай сделаем это по-быстрому...
Igor Khrol
 

Mais procurados (10)

Автоматическое тестирование Web api
Автоматическое тестирование Web apiАвтоматическое тестирование Web api
Автоматическое тестирование Web api
 
Grail - CodeFest'2015
Grail - CodeFest'2015Grail - CodeFest'2015
Grail - CodeFest'2015
 
Roslyn Code Analysis
Roslyn Code AnalysisRoslyn Code Analysis
Roslyn Code Analysis
 
Web driver история одной миграции
Web driver   история одной миграцииWeb driver   история одной миграции
Web driver история одной миграции
 
Тестирование весна 2014 смешанное занятие 2
Тестирование весна 2014 смешанное занятие 2Тестирование весна 2014 смешанное занятие 2
Тестирование весна 2014 смешанное занятие 2
 
Continuous Integration для тестировщиков
Continuous Integration для тестировщиковContinuous Integration для тестировщиков
Continuous Integration для тестировщиков
 
Qa Automation - отбрасываем лишнее и тестируем суть
Qa Automation - отбрасываем лишнее и тестируем сутьQa Automation - отбрасываем лишнее и тестируем суть
Qa Automation - отбрасываем лишнее и тестируем суть
 
Визуализация покрытия автоматизированными UI тестами
Визуализация покрытия автоматизированными UI тестамиВизуализация покрытия автоматизированными UI тестами
Визуализация покрытия автоматизированными UI тестами
 
Майстер-клас "Автоматизоване тестування. З чого почати?
Майстер-клас "Автоматизоване тестування. З чого почати?Майстер-клас "Автоматизоване тестування. З чого почати?
Майстер-клас "Автоматизоване тестування. З чого почати?
 
Cовременный контроль качества: давай сделаем это по-быстрому...
Cовременный контроль качества: давай сделаем это по-быстрому...Cовременный контроль качества: давай сделаем это по-быстрому...
Cовременный контроль качества: давай сделаем это по-быстрому...
 

Destaque (8)

Patterns of parallel programming
Patterns of parallel programmingPatterns of parallel programming
Patterns of parallel programming
 
Sql saturday azure storage by Anton Vidishchev
Sql saturday azure storage by Anton VidishchevSql saturday azure storage by Anton Vidishchev
Sql saturday azure storage by Anton Vidishchev
 
Bdd by Dmitri Aizenberg
Bdd by Dmitri AizenbergBdd by Dmitri Aizenberg
Bdd by Dmitri Aizenberg
 
Object-2-Object mapping, как приправа к вашему проекту
Object-2-Object mapping, как приправа к вашему проектуObject-2-Object mapping, как приправа к вашему проекту
Object-2-Object mapping, как приправа к вашему проекту
 
Microsoft Office 2013 новая модель разработки приложений
Microsoft Office 2013 новая модель разработки приложенийMicrosoft Office 2013 новая модель разработки приложений
Microsoft Office 2013 новая модель разработки приложений
 
Deep Dive C# by Sergey Teplyakov
Deep Dive  C# by Sergey TeplyakovDeep Dive  C# by Sergey Teplyakov
Deep Dive C# by Sergey Teplyakov
 
Async clinic by by Sergey Teplyakov
Async clinic by by Sergey TeplyakovAsync clinic by by Sergey Teplyakov
Async clinic by by Sergey Teplyakov
 
Mono
MonoMono
Mono
 

Semelhante a Design principles

Netpeak Talks #3: Масштабируемое приложение на PHP
Netpeak Talks #3: Масштабируемое приложение на PHPNetpeak Talks #3: Масштабируемое приложение на PHP
Netpeak Talks #3: Масштабируемое приложение на PHP
Образовательные мероприятия "Netpeak Talks"
 
SOLID & GRASP
SOLID & GRASPSOLID & GRASP
SOLID & GRASP
devel123
 
07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP
Edward Galiaskarov
 
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только одинSECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON
 

Semelhante a Design principles (20)

Solid code via tdd
Solid code via tddSolid code via tdd
Solid code via tdd
 
Проблемы точечной застройки в больших городах или зачем нужен Dagger
Проблемы точечной застройки в больших городах или зачем нужен DaggerПроблемы точечной застройки в больших городах или зачем нужен Dagger
Проблемы точечной застройки в больших городах или зачем нужен Dagger
 
Netpeak Talks #3: Масштабируемое приложение на PHP
Netpeak Talks #3: Масштабируемое приложение на PHPNetpeak Talks #3: Масштабируемое приложение на PHP
Netpeak Talks #3: Масштабируемое приложение на PHP
 
Принципы Solid на практике
Принципы Solid на практикеПринципы Solid на практике
Принципы Solid на практике
 
разработка бизнес приложений (7)
разработка бизнес приложений (7)разработка бизнес приложений (7)
разработка бизнес приложений (7)
 
Принципы SOLID
Принципы SOLIDПринципы SOLID
Принципы SOLID
 
SOLID
SOLIDSOLID
SOLID
 
разработка бизнес приложений (9)
разработка бизнес приложений (9)разработка бизнес приложений (9)
разработка бизнес приложений (9)
 
SOLIDарность: Тестирование как разработка
SOLIDарность: Тестирование как разработкаSOLIDарность: Тестирование как разработка
SOLIDарность: Тестирование как разработка
 
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)
 
SOLID & GRASP
SOLID & GRASPSOLID & GRASP
SOLID & GRASP
 
Корпоративное приложение на Rails
Корпоративное приложение на RailsКорпоративное приложение на Rails
Корпоративное приложение на Rails
 
Лучшие практики на практике
Лучшие практики на практикеЛучшие практики на практике
Лучшие практики на практике
 
Большие проекты, архитектура и фреймворки.
Большие проекты, архитектура и фреймворки.Большие проекты, архитектура и фреймворки.
Большие проекты, архитектура и фреймворки.
 
07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP
 
Архитектура в Agile: слабая связность
Архитектура в Agile: слабая связностьАрхитектура в Agile: слабая связность
Архитектура в Agile: слабая связность
 
Практическое применение принципа инверсии зависимостей на примере Ruby
Практическое применение принципа инверсии зависимостей на примере RubyПрактическое применение принципа инверсии зависимостей на примере Ruby
Практическое применение принципа инверсии зависимостей на примере Ruby
 
JavaScript design patterns overview
JavaScript design patterns overview JavaScript design patterns overview
JavaScript design patterns overview
 
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только одинSECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
SECON'2016. Сергей Аверин. Javascript-фреймворки:
 должен остаться только один
 
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только одинSECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
SECON'2016. Аверин Сергей, Javascript-фреймворки:
 должен остаться только один
 

Design principles

  • 1.
  • 2. Слабая связанность и критерии хорошего дизайна
  • 5. За день до релиза
  • 7. К чему стремимся • Гибкость • Надежность • Компонентность • Чистый и понятный код • Визуализация
  • 9. Single Responsibility Principle • Класс должен иметь лишь одну возможную причину для изменений.
  • 11. Open/Close Principle • Класс открыт для расширения – новое поведение может добавиться в будущем • Закрыт для модификации – изменения в код класса не допускаются
  • 13. Как это сделать? • Параметры – лямбда/делегаты • Наследование – дочерние классы переопределяют поведение родительского класса • Композиция/Strategy – передаем абстракцию – используем этот класс в существующем для реализации расширений
  • 14. Liskov Substitution Principle • Подтипы должны быть заменяемы базовыми типами
  • 15. Liskov Substition Principle • Is – a • Is – substitutable – for • Дочерние классы не должны нарушать поведения родительских контрактов (пред- условия и пост-условия)
  • 17. Liskov Substitution Principle • Создаем новый класс – два класса делят функциональность, но не заменяемы – можно создать 3 класс от которого пронаследовать эти два класс – Убедится что классы наследники и родитель заменяемы
  • 18. Interface Segregation Pinciple • Принцип разделения интерфейсов – Клиенты не должны зависить от методов которые они не используют
  • 19. Interface Segregation Principle • Лишняя абстракция в наследовании • «Жирный» интерфейс
  • 21. Dependency Inversion Principle • Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции. • Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
  • 22.
  • 23. Зависимости • Внешние библиотеки • База данных • Статические методы • New keyword • Сетевые взаимодействия • System Clock • Random
  • 24. Зависимости класса • Конструктор класса должен указывать зависимости в которых он нуждается (явные зависимости) • Остальные классы работают со скрытыми зависимостями
  • 26. Dependency Injection • Техника когда вызывающий класс поставляет(to inject) зависимости вызываемому классу • 3 основных способа: • Через конструктор • Через свойство • Через параметр
  • 27. Constructor Injection • За – четко выдны зависимости класса – можно работать как с контейнером так и без – класс всегда в валидном состоянии после создания • Против – может быть много параметров в конструкторе (ds) – не всем методам нужны переданные параметры (ds) – иногда нужен конструктор без параметров
  • 28. Property Injection • За – зависимость можно передать в любой момент – очень гибко • Против – Объект может быть в нестабильнос состоянии если какая-то из зависимостей не передана – менее явно
  • 29. Parameter Injection • За – Не нужно менять весь класс – очень гибко • Против – путает сигнатуру метода – много параметров (ds)
  • 30. Demo
  • 31. Где создавать объекты? • Конструктор по умолчанию без параметров (poor man’s ioc) • composition root • IoC container
  • 32. IoC Container • Инициализируют граф объектов • Регистрируют типы объектов • Разрешают типы объектов • Можно использовать как код так и конфигурацию