План

1. Критерии хорошего объектно-ориентированного дизайна.
2. Принцип единственной ответственности.
3. Принцип открытости-закрытости.
4. Принцип подстановки Барбары Лисков.
5. Принцип разделения интерфейса.
6. Принцип инверсии зависимостей.
7. Принцип Деметера.
8. Принцип ацикличности зависимостей.

Вопрос "Как писать хорошие программы на C++?" очень похож на вопрос "Как писать хорошую английскую прозу?". Есть два ответа: "Знай, что ты хочешь сказать" и "Практикуйтесь. Подражайте хорошему письму". Оба варианта, по–видимому, так же подходят для C++, как и для английского, и так же трудны для понимания. Основным идеалом для программирования на C++ – как и для программирования на большинстве языков более высокого уровня - является выражение концепций (идей, понятий и т.д.) из проекта непосредственно в коде.

Бьёрн Страуструп - Язык программирования C++

Какой дизайн нам нужен?

Какие концепции необходимо использовать?

Какую программу можно назвать хорошо спроектированной, а какую — плохо?

Если бы осьминоги умели считать, то какой бы системой они, скорее всего, пользовались?

Может ли человек умереть от компьютерного вируса?

Поговорим про коня в вакууме

Возможно (но это не точно) хорошим, то есть наиболее приемлемым как для производителя, так и для потребителя программного продукта является тот дизайн, который обеспечит:

• Наибольшую гибкость структуры ПО;
• Низкую стоимость сопровождения;
• Возможность повторного использования кода программ.

P.S. "Сферический конь в вакууме" - совершенно невозможное для применения на практике, однако в теории "живет и работает" прекрасно.

То, что в ООП не существует единственно правильных ответов, а только способы идентификации неправильных, лишний раз доказывает, что программирование является искусством.

В. В. Мухортов, В. Ю. Рылов - Объектно-ориентированное программирование, анализ и дизайн

Гибкость

— это возможность внесения изменений в код без существенной его переработки. Гибкость как свойство отображения требований пользователя на код программы есть мера устойчивости кода к изменениям требований.

А новые требования пользователя точно будут адекватными?

P.S. 10 типов заказчиков.

Стоимость сопровождения

— стоимость внесения изменений в фазе сопровождения ПО.

Повторное использование кода

— это возможность использовать единожды определенные абстракции (классы, модули) в разных компонентах одного и того же или различного ПО.

Пути удовлетворения критериям хорошего ОО дизайна

• Разработка дизайна иерархий классов (как собственно классов, так и отношений между ними);
• Разработка дизайна пакетов (содержимого пакетов и связей между ними);
• Поиск и повторное использования проверенных решений конкретных проблем.

P.S. У самурая нет тестов, только прод!

Разработка дизайна иерархий классов

— это про объектную декомпозицию!

Роберт Мартин (знаменитый в узких кругах блогер) разработал пять принципов объектно-ориентированного программирования и проектирования, говоря о которых, с подачи Майкла Фэзерса, используют акроним SOLID.

Следующий материал успешно украден адаптирован с хабра, который является переводом с blog.bitsrc.io.

Ну и еще использован методический материал из "В. В. Мухортов, В. Ю. Рылов - Объектно-ориентированное программирование, анализ и дизайн"

Адаптированный материал публикуется с сохранением условий распространения.

Что такое SOLID?

Расшифровка акронима SOLID

S: Single Responsibility Principle (Принцип единственной ответственности).
O: Open-Closed Principle (Принцип открытости-закрытости).
L: Liskov Substitution Principle (Принцип подстановки Барбары Лисков).
I: Interface Segregation Principle (Принцип разделения интерфейса).
D: Dependency Inversion Principle (Принцип инверсии зависимостей).

Максимально кратко про каждый принцип

S (Принцип единственной ответственности) — делай модули меньше.
O (Принцип открытости-закрытости) — делай модули расширяемыми.
L (Принцип подстановки Барбары Лисков) — наследуйся правильно.
I (Принцип разделения интерфейса) — дроби интерфейсы.
D (Принцип инверсии зависимостей) — используй интерфейсы.

S: Принцип единственной ответственности

Каждый класс должен решать лишь одну задачу.

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

Класс Animal, представленный здесь, описывает какое-то животное. Этот класс нарушает принцип единственной ответственности.

Он решает две, занимаясь работой с хранилищем данных в методе SaveAnimal и манипулируя свойствами объекта в конструкторе и в методе GetAnimalName.

Как такая структура класса может привести к проблемам?

Если изменится порядок работы с хранилищем данных, используемым приложением, то придётся вносить изменения во все классы, работающие с хранилищем.

Исправленный вариант:

Проектируя классы, мы должны стремиться к тому, чтобы объединять родственные компоненты, то есть такие, изменения в которых происходят по одним и тем же причинам. Нам следует стараться разделять компоненты, изменения в которых вызывают различные причины.

Стив Фентон - софтверный панк, автор, программист-архитектор, прагматик / абстракционист и специалист широкого профиля.

S: Классические примеры нарушения принципа

Объекты, которые могут печатать сами себя

Нужно выделить интерфейс Printer, от которого можно будет сделать PlainTextPrinter и HtmlPrinter.

Объекты, которые могут сохранять сами себя

Нужно выделить интерфейс Storage, от которого можно будет сделать DB и File.

S: Признаки нарушения принципа

• Затруднения с выбором подходящего имени класса;
• Большое количество методов в классе;
• Большое количество входящих и/или исходящих зависимостей;
• Систематическое нарушение других принципов дизайна.

S по версии Р. Мартина

ORR (One responsibility Rule) — правило единственности абстракции.

Класс должен обладать единственной ответственностью, реализуя ее полностью, реализуя ее хорошо и реализуя только ее.

O: Принцип открытости-закрытости

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

Какие проблемы имеются тут?

Функция AnimalSound не соответствует принципу открытости-закрытости. Изменения в содержимом контейнера:

влечет изменения AnimalSound:

Исправленный вариант:

У класса Animal теперь есть виртуальный метод MakeSound(). При таком подходе нужно, чтобы классы, предназначенные для описания конкретных животных, расширяли бы класс Animal и реализовывали бы этот метод.

O: Классический пример нарушения принципа

Решено было разделить клиентов на две группы. Любимым (fav) клиентам даётся скидка в 20%, а VIP-клиентам (vip) — удвоенная скидка, то есть — 40%.

Исправленный вариант:

Тут используется расширение возможностей классов, а не их модификация.

L: Принцип подстановки Барбары Лисков

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

Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается.

Что тут нарушено?

P.S. Статья о том, как получить реальный тип объекта в C++.

Функция AnimalLegCount нарушает и принцип подстановки, и принцип открытости-закрытости.

Для того чтобы эта функция не нарушала принцип подстановки, нужно выполнить требование, сформулированное Стивом Фентоном:

Методы, принимающие или возвращающие значения с типом некоего суперкласса должны также принимать и возвращать значения, типами которых являются его подклассы.

А мы такое уже делали:

L по версии Р. Мартина

LSP (Liskov Substitution Principle) — принцип подстановки Лисковой.

Методы, принимающие в качестве параметра указатели и ссылки на объекты базового класса должны иметь возможность использовать эти объекты без необходимости знать, к какому классу (базовому или любому из производных) они принадлежат.

I: Принцип разделения интерфейса

Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют.

Этот принцип направлен на устранение недостатков, связанных с реализацией больших интерфейсов.

Рассмотрим интерфейс Shape:

Он описывает методы для рисования кругов (DrawCircle), квадратов (DrawSquare) и прямоугольников (DrawRectangle). В результате классы, реализующие этот интерфейс и представляющие отдельные геометрические фигуры, такие, как круг (Circle), квадрат (Square) и прямоугольник (Rectangle), должны содержать реализацию всех этих методов.

Странный получился код? А чем еще это грозит?

Предположим, мы решим добавить в интерфейс Shape ещё один метод, DrawTriangle, предназначенный для рисования треугольников:

Это приведёт к тому, что классам, представляющим конкретные геометрические фигуры, придётся реализовывать ещё и метод DrawTriangle. В противном случае возникнет ошибка.

Исправленный вариант:

I по версии Р. Мартина

ISP (Interface Segregation Principle) — принцип разделения интерфейсов

Классы не должны зависеть от контрактов, которых они не используют.

P.S. На фото Роберт Мартин рассказывает о SOLID джуну

D: Принцип инверсии зависимостей

Объектом зависимости должна быть абстракция, а не что-то конкретное.

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Здесь класс Http представляет собой высокоуровневый компонент, а XMLHttpService — низкоуровневый.

Где в структуре скрываются проблемы?

1. Нарушение принципа инверсии зависимостей, а именно "модули верхних уровней не должны зависеть от модулей нижних уровней".
2. Класс Http вынужденно зависит от класса XMLHttpService. Если мы решим изменить механизм, используемый классом Http для взаимодействия с сетью — скажем, это будет Node.js-сервис или, например, сервис-заглушка, применяемый для целей тестирования (англ. mock - имитация), нам придётся отредактировать все экземпляры класса Http, изменив соответствующий код. Это нарушает принцип открытости-закрытости.

Исправленный вариант:

Как можно заметить, здесь высокоуровневые и низкоуровневые модули зависят от абстракций. Класс Http (высокоуровневый модуль) зависит от интерфейса Connection (абстракция). Классы XMLHttpService и MockService (низкоуровневые модули) также зависят от интерфейса Connection.

Кроме того, стоит отметить, что следуя принципу инверсии зависимостей, мы соблюдаем и принцип подстановки Барбары Лисков. А именно, оказывается, что типы XMLHttpService и MockService могут служить заменой базовому типу Connection.

D по версии Р. Мартина

DIP (Dependency Inversion Principle) — принцип инверсии зависимости

Модули высокого уровня не должны зависеть от модулей низкого. И те, и другие, должны зависеть от абстракций. Абстракции не должны зависеть от деталей реализации.

P.S. Роберт Мартин показывает максимальную оценку за экзамен прогульщиков.

Принцип Деметера

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

Ян Холланд

Оригинальная формулировка этого принципа, возникшая в процессе работы над одноименным проектом (Demeter) в Северо-Восточный университет (Бостон) осенью 1987 года.

Принцип Деметера не ограничивается классами.

Одна из формулировок принципа Деметера звучит так:

Разговаривайте только с близкими друзьями. Никогда не разговаривайте с незнакомцами.

Минимизируйте связывание между модулями

Э. Хант, Д. Томас. "Программист-прагматик"

Пример из книги:

Закон Деметры для функций гласит, что любой метод некоторого объекта может обращаться только к методам принадлежащим: самим себе (1); любым параметрам , переданным в метод (2); любым создаваемым им объектам (3); любым непосредственно содержащимся объектам компонентов (4).

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

Гради Буч, один из создателей UML

Принцип ацикличности зависимостей (Р. Мартин)

ADP (Acyclic Dependencies Principle) — принцип ацикличности зависимостей

Структура зависимостей между элементами (классами, пакетами, методами) должна представлять собой направленный ациклический граф.

Принцип в равной степени применим ко всем элементам ПО.

Ориентированный ациклический граф:

Изменение компонента Database (который нужно собрать вместе с компонентов Entitities) затронет только компонент Main.

Ориентированный граф с циклами:

Изменение Database требует проверки работы с Entities, но Entities зависит от Authorizer, который зависит от Interactors. По сути Database, Entities, Authorizer,Interactors вместе становятся одним большим компонентом.

Стратегии прерывания цикла

Циклы в зависимостях делают код более хрупким. Стратегии разорвать цепочку циклических зависимостей:

• Принцип инверсии зависимостей;
• Создать новый пакет и переместить туда общие зависимости.

Вопросы?

P.S. Р. Мартин не доволен тем, что джуны не читают его книг