Если вы знакомы с языком программирования Java, то наверняка слышали о концепциях ООП.

В объектно-ориентированном программировании есть четыре основных понятия: -
1) Инкапсуляция
2) Абстракция
3) Наследование
4) Полиморфизм

После получения знаний о четырех основных концепциях, приведенных выше, при разработке программного обеспечения вы должны знать о принципах S.O.L.I.D.

Эти пять принципов разработки программного обеспечения являются рекомендациями, которым следует следовать при создании программного обеспечения, чтобы его было легче масштабировать и поддерживать. Их сделал популярным инженер-программист Роберт С. Мартин.

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

Давайте начнем!

Принципы SOLID

S — единая ответственность

"У класса должна быть одна и только одна причина для изменения, что означает, что у класса должна быть только одна работа"

Этот принцип хорошо сформулирован Робертом Мартином, который утверждает, что «у класса должна быть одна и только одна причина для изменения». Следование этому принципу означает, что каждый класс делает только одну вещь, и каждый класс или модуль отвечает только за один аспект функциональности программного обеспечения. Иными словами, каждый класс должен работать только над одной проблемой.

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

Цель
Этот принцип направлен на разделение поведения, чтобы, если ошибки возникнут в результате вашего изменения, они не повлияли на несвязанное поведение.

O – открыто/закрыто

"Объекты или сущности должны быть открыты для расширения, но закрыты для модификации"

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

⁜ Открытодля расширения, что означает возможность изменения поведения класса;

⁜ Закрытодля модификации. Это означает, что исходный код был установлен и не может быть изменен.

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

L — Замена Лисков

"Каждый подкласс/производный класс должен иметь возможность заменить родительский/базовый класс"

Принцип замещения Лискова, пожалуй, самый трудный для понимания из пяти принципов SOLID. В общем, этот принцип гласит, что каждый производный класс должен быть взаимозаменяемым со своим родительским классом. Барбара Лисков, которая в 1987 году ввела концепцию поведенческих подтипов, удостоилась имени этого принципа.

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

Цель
Этот принцип направлен на обеспечение согласованности, чтобы родительский класс и его дочерний класс можно было использовать одинаково без ошибок.

I — Разделение интерфейса

«Клиентов нельзя заставлять применять методы, которые они не используют»

Общая идея принципа разделения интерфейсов заключается в том, что лучше иметь много меньших интерфейсов, чем несколько больших. Мартин объясняет этот принцип, советуя: «Создавайте детализированные интерфейсы, ориентированные на клиента. Клиентов не следует заставлять реализовывать интерфейсы, которые они не используют».

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

D — инверсия зависимостей

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

Этот принцип обеспечивает метод разделения программных модулей. Проще говоря, принцип инверсии зависимостей гласит, что разработчики должны «полагаться на абстракции, а не на конкретику». Мартин развивает этот принцип, заявляя, что «модули высокого уровня не должны полагаться на модули низкого уровня». Оба должны основываться на абстракциях. Более того, «абстракции не должны зависеть от конкретики. Детали должны основываться на абстракциях».

Цель
Этот принцип направлен на уменьшение зависимости высокоуровневого класса от низкоуровневого класса за счет введения интерфейса.

РЕЗЮМЕ
До сих пор мы говорили об этих пяти принципах. Они предназначены для того, чтобы помочь вам сделать ваш код простым для модификации, расширения и тестирования.

Большое спасибо, что нашли время, чтобы прочитать это. Надеюсь, теперь вы лучше разбираетесь в этом вопросе.