Перейти к содержанию

ООП. Принципы SOLID

Общие сведения

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

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

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

Но, как и всё в этой жизни, соблюдение этих принципов имеет свою цену. Здесь это в основном выражается в усложнении кода программы. В реальной жизни, пожалуй, нет такого кода, в котором бы соблюдались все эти принципы сразу. Поэтому помните о балансе и не воспринимайте всё изложенное как догму.

Подробнее:

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

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

Подробнее:

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

Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации. Например, с C# мы можем использовать для этого наследование от абстрактного интерфейса, при этом конкретная реализация программной сущности даже может быть вынесена в отдельный модуль и подключаться через механизм инверсии зависимостей.

Подробнее:

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

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

Подробнее:

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

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

Подробнее:

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

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

Данный принцип гласит, что,

  • во-первых, программные сущности высокого уровня не должны зависеть от низкоуровневых программных сущностей. При этом оба должны зависеть от абстракций.
  • Во-вторых, абстракции не должны зависеть от деталей, но детали должны зависеть от абстракций.

Классы высокого уровня реализуют бизнес-правила или логику в системе (приложении). Низкоуровневые классы занимаются более подробными операциями, другими словами, они могут заниматься записью информации в базу данных или передачей сообщений в операционную систему или службы и т.п.

Подробнее:

DIP