SOLID — это набор популярных принципов проектирования, используемых при разработке объектно-ориентированного программного обеспечения. SOLID — это аббревиатура, обозначающая пять основных принципов дизайна.
· S — принцип единой ответственности
· O — принцип открытого-закрытого
· L — принцип подстановки Лискова
· I — Принцип разделения интерфейсов
· D — принцип инверсии зависимостей
Это пять основных принципов дизайна. Мы обсудим эти пять принципов один за другим.
Принцип единой ответственности
Для изменения класса должна быть только одна причина, то есть класс должен иметь только одну работу.
Его можно применять к классам, а также к программным компонентам и микросервисам.
Мы можем извлечь много пользы из использования этого единственного Принципа Ответственности. Преимущества, такие как снижение частоты и влияния изменений и простота понимания.
Есть много реальных примеров этого принципа единственной ответственности. Вы найдете множество примеров всех принципов проектирования SOLID, которые можно найти в программном обеспечении с открытым исходным кодом, а также во многих хорошо разработанных приложениях. Например, ваш уровень персистентности Java и популярные фреймы и спецификации, которые вы часто используете для его выполнения.
Одним из них является спецификация Java Persistence API (JPA). У него одна и та же ответственность. То есть определение стандартизированного метода управления существующими данными в базе данных контактов с использованием концепции сопоставления объектов и контактов.
Принцип открытого-закрытого
В соответствии с этим принципом программные объекты (классы, модули, функции и т. д.) должны быть открыты для расширений, но закрыты для модификации.
Общая идея этого принципа заключается в том, чтобы написать свой код так, чтобы вы могли добавлять новые функции, не изменяя существующий код.
давайте подумаем на примере. рассмотрим приложение, которое берет набор фигур — кругов и квадратов — и вычисляет сумму площадей всех фигур в наборе.
Мы можем рассчитать TotalArea, используя классы House и AreaCalcalator следующим образом.
Мы можем вычислить TotalArea кругов и квадратов таким образом, но если вы хотите вычислить TotalArea кругов, квадратов и других треугольников, вы не можете использовать этот метод.
Потому что этот путь открыт для модификации. Поэтому мы можем использовать для этого интерфейс Shape. Кроме того, мы можем разделить круг, квадрат и треугольник на подклассы. Используя интерфейс формы, мы можем вычислить площадь любой формы следующим образом.
Этот способ следует принципу открытого-закрытого. Поскольку это закрыто для модификации, откройте для расширения.
Принцип замены Лисков
Этот принцип гласит, что каждый подкласс/производный класс должен иметь возможность заменить свой родительский/первичный класс. То есть при расширении класса дочерние классы должны выполнять основные функции базового класса. Кроме того, дочерний класс не должен придавать другое значение методам, существующим в родительском классе, после их переопределения. Также в дочерних классах не должно быть нереализованных методов.
Давайте возьмем пример, рассмотрим Fish как родительский класс. У него есть много подклассов, таких как Акула и Золотая рыбка. Также предположим, что у нас есть метод плавания к родительскому классу рыб. Поэтому этот метод также следует включить в подклассы Shark и Goldfish.
Кроме того, Goldfish и Sharks расширяют родительский класс, но не должны действовать иначе, чем существующее значение родительского класса. Таким образом, подклассы не могут делать такие вещи, как полет, ходьба. Он может только плавать, но его также можно расширить как что-то вроде быстрого плавания, медленного плавания.
Принцип разделения интерфейса
В соответствии с этим принципом клиент никогда не должен быть принужден к реализации интерфейса, который он не использует, или клиенты не должны зависеть от методов, которые они не используют.
Подобно принципу единой ответственности, принцип разделения интерфейса направлен на снижение частоты побочных эффектов и необходимых изменений путем разделения программного обеспечения на несколько независимых разделов.
Принцип инверсии зависимости
У нас есть два модуля: высокоуровневый и низкоуровневый. Обычно модули высокого уровня близки к бизнес-задачам и изменяются только в связи с изменением бизнеса. Это не изменится по какой-либо технической причине, например, переход на новую структуру, необходимость переключения базы данных.
Модули низкого уровня зависят от всех остальных модулей. Также это должно зависеть от модулей бизнес-уровня.
Согласно определению этого принципа, Сущности должны зависеть от абстракций, а не от конкретики. В нем говорится, что модуль высокого уровня не должен зависеть от модуля низкого уровня, но они должны зависеть от абстракций.
