Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design principles

2,955 views

Published on

  • Be the first to comment

  • Be the first to like this

Design principles

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

×