SOLID – принципы объектно-ориентированного дизайна

2.  Что такое «плохой» дизайн кода
 в чем он выражается
 какие несет проблемы
 Принципы проектирования SOLID
 Назначение
 Примеры использования
 Как обнаруживать и устранять плохой дизайн
кода
 Запахи кода
 Системы статического анализа кода

4.  Повторение
 Отсутствие возможности повторного
использования кода
 Монолитность
 Плохая читаемость кода
 Неоправданная сложность
 Вязкость
 Хрупкость

6.  Внесение изменений в систему, которая
проектировалась без учета возможности
появления таковых
 Изменения в системе могут потребоваться
на любой стадии проекта:
 Аналитика
 Разработка
 Сопровождение

7.  Отсутствие формализированных
требований со стороны клиента
 Уточнение требований на этапе
разработки, после утверждения ТЗ
 Реализация дополнительного
функционала на этапе технического
сопровождения системы

8.  Мы должны помнить об этом
 Строить процесс разработки итеративно, с
поправкой на то, чтобы внесение
последующих изменений стоило нам как
можно меньше ресурсов

10. Дубликаты
структур, которые должны
иметь общую абстракцию.

11. Сложно выделить компоненты, которые
можно использовать повторно

12. Систему сложно изменять

14. В системе есть инфраструктура, которая или
не используется, или используется
неправильно

15. Делать что-то правильно сложнее, чем
делать это неправильно

16. Изменения легко ломают
систему и приводят к
новым изменениям

18.  Single Responsibility
 Open/Closed
 Liskov Substitution
 Interface Segregation
 Dependency Inversion

19. SOLID - это аббревиатура пяти основных
принципов дизайна классов в объектно-
ориентированном проектировании

20. Были сформулированы Робертом Мартином
в далеком 1995 году

22. У класса есть только одна
ответственность, он умеет ее делать и делает
ее хорошо.
Не должно быть больше одной причины для
изменения класса.

23. Пример приложения «Прямоугольник»:
Требования:
Расчет площади прямоугольника
Вывод изображения прямоугольника на UI

26. Пример приложения «Модем»:
Требования:
Установка соединения по телефонному
номеру
Завершение соединения
Отправка данных
Прием данных

29. У класса есть только одна
ответственность, он умеет ее делать и делает
ее хорошо.
Не должно быть больше одной причины для
изменения класса.

31. Программные сущности
(классы, модули, методы и т.д.) должны
быть открыты для расширения, но
закрыты от изменений

32. Как этого добиться?

33. Классы должны зависеть от абстракций
Новые фичи могут быть добавлены путем
реализации абстракций

34. Использование паттернов
 Стратегия
 Шаблонный метод

35. Приложение «Почтовый клиент»
Требования:
Отправка почты
Запись результатов работы в файл

38. Приложение «Почтовый клиент»
Новое требование:
Запись результатов работы на диск

41. Паттерн Стратегия

45. Паттерн Шаблонный метод

46. Задача:
Разработать класс, реализующий
шифрование данных при помощи
алгоритмов DES и RSA

50. Программные сущности
(классы, модули, методы и т.д.) должны
быть открыты для расширения, но
закрыты от изменений

52. Пусть q(x) является свойством, верным
относительно объектов x некоторого типа T.
Тогда q(y) также должно быть верным для
объектов y типа S, где S является подтипом
типа T.

53. Клиенты, использующие базовый
класс, должны работать и с его
наследниками, не зная этого

54. Задача
Мы хотим реализовать свой список с интерфейсом IList<T>. Его особенностью будет
то, что все записи в нем дублируются.
Данная реализация не представляет никакой опасности, если рассматривать ее
изолированно.

55. Взглянем на использование этого
класса с точки зрения клиента.
Клиент, абстрагируясь от
реализаций, пытается работать со
всеми объектами типа IList
одинаково:

56. Поведение списка DoubleList отличается от типичных
реализаций IList. Получается, что наш DoubleList не может быть
заменен базовым типом. Это и есть нарушение принципа
замещения Лисков.
Проблема заключается в том, что теперь клиенту необходимо
знать о конкретном типе объекта, реализующем
интерфейс IList. В качестве такого объекта могут передать
и DoubleList, а для него придется выполнять дополнительную
логику и проверки.

57. Решение
Правильным решением будет использовать свой собственный
интерфейс, например, IDoubleList.
Этот интерфейс будет объявлять для пользователей
поведение, при котором добавляемые элементы удваиваются.

58. Проектирование по контракту

59.  Предусловия не могут быть
ужесточены в наследнике
 Постусловия не могут быть ослаблены
в наследнике
 Инварианты базового типа должны
соблюдаться и в наследнике

60. Рассмотрим пред и постусловия для интерфейса IList.
Для функции Add:
•предусловие: item != null
•постусловие: count = oldCount + 1
Для нашего DoubleList и его функции Add:
•предусловие: item != null
•постусловие: count = oldCount + 2

63. Клиентам не должны навязываться
интерфейсы, которые им не нужны

66. Много небольших интерфейсов лучше
чем один большой

68.  Зависимости внутри системы строятся на
основе абстракций.
 Модули верхнего уровня не зависят от
модулей нижнего уровня.
 Абстракции не должны зависеть от
деталей. Детали должны зависеть от
абстракций.

69. Приложение «Печатная машинка»
Приложение должно уметь:
 Читать текст с клавиатуры
 Выводить текст на печать на принтер

72. Приложение «Печатная машинка»
Появилось новое требование
 Приложение должно уметь сохранять
текст на диск

74. Пример применения принципа DI

77. Отсутствие инверсии зависимостей не
всегда плохо.
Пример, зависимость от класса String.

78.  Зависимости внутри системы строятся на
основе абстракций.
 Модули верхнего уровня не зависят от
модулей нижнего уровня.
 Абстракции не должны зависеть от
деталей. Детали должны зависеть от
абстракций.

81. Проводить ревью кода
Находить «запахи» кода
Использовать статические анализаторы кода

86. You Aren’t Gonne Need It
Keep It Simple Stupid

87.  Что такое плохой дизайн и откуда он берется
 Как использовать принципы SOLID для
улучшения дизайна
 Как поддерживать код в хорошем состоянии

88.  Материалы xpinjection.com - http://xpinjection.com/resources/
 Блог Александра Бындю - http://blog.byndyu.ru/
 Книга «Принципы, паттерны и методики гибкой разработки на языке C#» -
http://www.ozon.ru/context/detail/id/5800704/
 Книга «Инфраструктура программных проектов. Соглашения, идиомы и
шаблоны для многократно используемых библиотек .NET» -
http://www.ozon.ru/context/detail/id/5588868/

89.  Трѐшников Павел
 Ведущий разработчик СМС-ИТ
▪ www.sms-automation.ru
 e-mail: treshnikov@gmail.com
 twitter: @treshnikov