Принципы SOLID в картинках / Хабр

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

В Сети множество отличных статей, где рассказывается о принципах SOLID, но иллюстрированных среди них мне практически не попадалось. Из-за этого таким людям со склонностью к визуальному восприятию информации – таким, как я – бывает сложно схватывать суть и не отвлекаться.

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

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

Ну, приступим.

Принципы SOLID

S – Single Responsibility (Принцип единственной ответственности)

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

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

Назначение

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

O — Open-Closed (Принцип открытости-закрытости)

Классы должны  быть  открыты для расширения, но закрыты для модификации.

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

Назначение

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

L — Liskov Substitution (Принцип подстановки Барбары Лисков)

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

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

Если у вас имеется класс и вы создаете на его базе другой класс, исходный класс становится родителем, а новый – его потомком. Класс-потомок должен производить такие же операции, как и класс-родитель. Это называется наследственностью.

Необходимо, чтобы класс-потомок был способен обрабатывать те же запросы, что и родитель, и выдавать тот же результат. Или же результат может отличаться, но при этом относиться к тому же типу. На картинке это показано так: класс-родитель подаёт кофе (в любых видах), значит, для класса-потомка приемлемо подавать капучино (разновидность кофе), но неприемлемо подавать воду.

Если класс-потомок не удовлетворяет этим требованиям, значит, он слишком сильно отличается от родителя и нарушает принцип.

Назначение

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

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

Не следует ставить клиент в зависимость от методов, которые он не использует.

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

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

Назначение

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

D — Dependency Inversion (Принцип инверсии зависимостей)

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

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

Модули (или классы) верхнего уровня = классы, которые выполняют операцию при помощи инструмента

Модули (или классы) нижнего уровня = инструменты, которые нужны для выполнения операций

Абстракции – представляют интерфейс, соединяющий два класса

Детали = специфические характеристики работы инструмента

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

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

Назначение

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

Обобщая сказанное

Мы разобрали все пять принципов и сформулировали для каждого назначение. Всё это призвано помочь вам писать код, который можно модифицировать, расширять и тестировать с минимумом проблем. Спасибо, что прочитали; надеюсь, вы получили не меньше удовольствия, чем я в процессе работы над статьёй.

Принципы SOLID, о которых должен знать каждый разработчик | by Nikita | WebbDEV

Еще больше полезной информации для программистов вы найдете на нашем сайте.

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

Вот как расшифровывается акроним SOLID:

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

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

«Одно поручение. Всего одно.» — Локи говорит Скурджу в фильме «Тор: Рагнарёк».
Каждый класс должен решать лишь одну задачу.

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

Обратите внимание на то, что этот принцип применим не только к классам, но и к компонентам программного обеспечения в более широком смысле.

Например, рассмотрим этот код:

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

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

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

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

Для того чтобы привести вышеприведённый код в соответствие с принципом единственной ответственности, создадим ещё один класс, единственной задачей которого является работа с хранилищем, в частности — сохранение в нём объектов класса Animal:

Вот что по этому поводу говорит Стив Фентон: «Проектируя классы, мы должны стремиться к тому, чтобы объединять родственные компоненты, то есть такие, изменения в которых происходят по одним и тем же причинам. Нам следует стараться разделять компоненты, изменения в которых вызывают различные причины».

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

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

Продолжим работу над классом Animal.

Мы хотим перебрать список животных, каждое из которых представлено объектом класса Animal, и узнать о том, какие звуки они издают. Представим, что мы решаем эту задачу с помощью функции AnimalSounds:

Самая главная проблема такой архитектуры заключается в том, что функция определяет то, какой звук издаёт то или иное животное, анализируя конкретные объекты. Функция AnimalSound не соответствует принципу открытости-закрытости, так как, например, при появлении новых видов животных, нам, для того, чтобы с её помощью можно было бы узнавать звуки, издаваемые ими, придётся её изменить.

Добавим в массив новый элемент:

После этого нам придётся поменять код функции AnimalSound:

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

Как привести функцию AnimalSound в соответствие с принципом открытости-закрытости? Например — так:

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

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

Если теперь добавить в массив объект, описывающий новое животное, функцию AnimalSound менять не придётся. Мы привели её в соответствие с принципом открытости-закрытости.

Рассмотрим ещё один пример.

Представим, что у нас есть магазин. Мы даём клиентам скидку в 20%, используя такой класс:

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

Такой подход нарушает принцип открытости-закрытости. Как видно, здесь, если нам надо дать некоей группе клиентов особую скидку, приходится добавлять в класс новый код.

Для того чтобы переработать этот код в соответствии с принципом открытости-закрытости, добавим в проект новый класс, расширяющий класс Discount. В этом новом классе мы и реализуем новый механизм:

Если решено дать скидку в 80% «супер-VIP» клиентам, выглядеть это должно так:

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

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

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

Рассмотрим применение этого принципа, вернувшись к примеру с классом Animal. Напишем функцию, предназначенную для возврата информации о количествах конечностей животного.

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

Для того чтобы эта функция не нарушала принцип подстановки, преобразуем её с использованием требований, сформулированных Стивом Фентоном. Они заключаются в том, что методы, принимающие или возвращающие значения с типом некоего суперкласса (Animal в нашем случае) должны также принимать и возвращать значения, типами которых являются его подклассы (Pigeon).

Вооружившись этими соображениями мы можем переделать функцию AnimalLegCount:

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

Теперь в классе Animal должен появиться метод LegCount:

А его подклассам нужно реализовать этот метод:

В результате, например, при обращении к методу LegCount для экземпляра класса Lion производится вызов метода, реализованного в этом классе, и возвращается именно то, что можно ожидать от вызова подобного метода.

Теперь функции AnimalLegCount не нужно знать о том, объект какого именно подкласса класса Animalона обрабатывает для того, чтобы узнать сведения о количестве конечностей у животного, представленного этим объектом. Функция просто вызывает метод LegCount класса Animal, так как подклассы этого класса должны реализовывать этот метод для того, чтобы их можно было бы использовать вместо него, не нарушая правильность работы программы.

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

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

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

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

Странный у нас получился код. Например, класс Rectangle, представляющий прямоугольник, реализует методы (drawCircle и drawSquare), которые ему совершенно не нужны. То же самое можно заметить и при анализе кода двух других классов.

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

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

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

Принцип разделения интерфейса предостерегает нас от создания интерфейсов, подобных Shape из нашего примера. Клиенты (у нас это классы Circle, Square и Rectangle) не должны реализовывать методы, которые им не нужно использовать. Кроме того, этот принцип указывает на то, что интерфейс должен решать лишь какую-то одну задачу (в этом он похож на принцип единственной ответственности), поэтому всё, что выходит за рамки этой задачи, должно быть вынесено в другой интерфейс или интерфейсы.

В нашем же случае интерфейс Shape решает задачи, для решения которых необходимо создать отдельные интерфейсы. Следуя этой идее, переработаем код, создав отдельные интерфейсы для решения различных узкоспециализированных задач:

Теперь интерфейс ICircle используется лишь для рисования кругов, равно как и другие специализированные интерфейсы — для рисования других фигур. Интерфейс Shape может применяться в качестве универсального интерфейса.

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

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

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

Здесь класс Http представляет собой высокоуровневый компонент, а XMLHttpService — низкоуровневый. Такая архитектура нарушает пункт A принципа инверсии зависимостей: «Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций».

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

Класс Http не должен знать о том, что именно используется для организации сетевого соединения. Поэтому мы создадим интерфейс Connection:

Интерфейс Connection содержит описание метода request и мы передаём классу Http аргумент типа Connection:

Теперь, вне зависимости от того, что именно используется для организации взаимодействия с сетью, класс Http может пользоваться тем, что ему передали, не заботясь о том, что скрывается за интерфейсом Connection.

Перепишем класс XMLHttpService таким образом, чтобы он реализовывал этот интерфейс:

В результате мы можем создать множество классов, реализующих интерфейс Connection и подходящих для использования в классе Http для организации обмена данными по сети:

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

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

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

Еще больше полезной информации для программистов вы найдете на нашем сайте.

Важность принципов проектирования SOLID — BMC Software

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

Принципы SOLID были разработаны Робертом С. Мартином в эссе 2000 года «Принципы проектирования и шаблоны проектирования», хотя аббревиатура была придумана позже Майклом Фезерсом. В своем эссе Мартин признал, что успешное программное обеспечение будет меняться и развиваться. По мере его изменения он становится все более сложным. Мартин предупреждает, что без хороших принципов проектирования программное обеспечение становится жестким, хрупким, неподвижным и вязким. Принципы SOLID были разработаны для борьбы с этими проблемными шаблонами проектирования.

Широкая цель принципов SOLID — уменьшить количество зависимостей, чтобы инженеры могли изменять одну область программного обеспечения, не затрагивая другие. Кроме того, они предназначены для облегчения понимания, поддержки и расширения проектов. В конечном счете, использование этих принципов проектирования позволяет инженерам-программистам избегать проблем и создавать адаптивное, эффективное и гибкое программное обеспечение.

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

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

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

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

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

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

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

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

Идея принципа открытости-закрытости состоит в том, что существующие, хорошо протестированные классы необходимо модифицировать, когда нужно что-то добавить. Тем не менее, изменение классов может привести к проблемам или ошибкам. Вместо изменения класса вы просто хотите его расширить. Имея в виду эту цель, Мартин резюмирует этот принцип: «Вы должны иметь возможность расширять поведение класса, не изменяя его».

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

1. Открыт для расширения, что означает возможность расширения поведения класса; и
2. Закрыто для модификации, что означает, что исходный код установлен и не может быть изменен.

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

Принцип замещения Лисков

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

Здесь требуется что-то вроде следующего свойства подстановки: если для каждого объекта O1 типа S существует объект O2 типа T такой, что для всех программ P, определенных в терминах T, поведение P не меняется, когда O1 заменяется на O2, тогда S является подтипом T.

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

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

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

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

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

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

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

Одним из популярных способов соблюдения этого принципа является использование шаблона инверсии зависимостей, хотя этот метод не является единственным. Какой бы метод вы ни выбрали, поиск способа использования этого принципа сделает ваш код более гибким, гибким и пригодным для повторного использования.

Заключение

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

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

Эти сообщения являются моими собственными и не обязательно отражают позицию, стратегию или мнение BMC.

Видите ошибку или есть предложение? Пожалуйста, сообщите нам об этом по электронной почте [email protected].

Принцип SOLID в программировании: понимание на примерах из реальной жизни

В разработке программного обеспечения Объектно-ориентированный дизайн играет решающую роль, когда речь идет о написании гибкого, масштабируемого, поддерживаемого и многократно используемого кода. Существует так много преимуществ использования OOD, но каждый разработчик должен также знать принцип SOLID для хорошего объектно-ориентированного проектирования в программировании. Принцип SOLID был введен Robert C. Martin , также известный как Uncle Bob , является стандартом кодирования в программировании. Этот принцип является аббревиатурой пяти принципов, которые приведены ниже…

1. Принцип единой ответственности (SRP)
2. Принцип открытой/закрытой
3. Принцип замещения Лискова (LSP)
4. Принцип разделения интерфейса (ISP)
5. Принцип инверсии зависимостей (DIP)

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

1. Принцип единой ответственности: Этот принцип гласит, что « класс должен иметь только одну причину для изменения », что означает, что каждый класс должен иметь одну обязанность, одну работу или одну цель. Возьмем пример разработки программного обеспечения. Задача разделена на разных участников, выполняющих разные задачи: дизайнеры интерфейса занимаются дизайном, тестировщик занимается тестированием, а разработчик бэкенда занимается частью разработки бэкэнда, тогда мы можем сказать, что у каждого есть одна работа или ответственность.
В большинстве случаев, когда программистам нужно добавить функции или новое поведение, они реализуют все в существующем классе, что совершенно неправильно. Это делает их код длинным, сложным и отнимает время, когда позже что-то нужно изменить. Используйте слоев в своем приложении и разбейте классы Бога на более мелкие классы или модули.

2. Принцип открытости/закрытости: Этот принцип гласит, что « программные объекты (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации », что означает, что вы должны иметь возможность расширять поведение класса, не изменяя его.
Предположим, что разработчику A необходимо выпустить обновление для библиотеки или платформы, а разработчик B хочет изменить или добавить какую-либо функцию, тогда разработчику B разрешено расширять существующий класс, созданный разработчиком A, но разработчик B не должен изменять класс напрямую. Использование этого принципа позволяет отделить существующий код от модифицированного, что обеспечивает лучшую стабильность, удобство сопровождения и сводит к минимуму изменения, как в вашем коде.

3. Принцип замещения Лисков: Принцип был введен Барбарой Лисков в 1987 году и в соответствии с этим принципом « Производные или дочерние классы должны быть заменяемыми для своих базовых или родительских классов ». Этот принцип гарантирует, что любой класс, который является дочерним по отношению к родительскому классу, можно использовать вместо своего родителя без какого-либо неожиданного поведения.
Вы можете понять это так, что сын фермера должен унаследовать навыки земледелия от своего отца и должен быть в состоянии заменить своего отца, если это необходимо. Если сын хочет стать фермером, он может заменить своего отца, но если он хочет стать игроком в крикет, то сын определенно не может заменить своего отца, даже если они оба принадлежат к одной и той же семейной иерархии.
Одним из классических примеров применения этого принципа является прямоугольник с четырьмя сторонами. Высота прямоугольника может быть любым значением, а ширина может быть любым значением. Квадрат – это прямоугольник с одинаковой шириной и высотой. Таким образом, мы можем сказать, что можем расширить свойства класса прямоугольника до класса квадрата. Для этого вам нужно поменять местами дочерний (квадратный) класс с родительским (прямоугольным) классом, чтобы он соответствовал определению квадрата с четырьмя равными сторонами, но производный класс не влияет на поведение родительского класса, поэтому, если вы сделаете что это нарушит принцип подстановки Лисков. Проверьте ссылку Принцип замещения Лисков для лучшего понимания.

4. Принцип разделения интерфейсов: Этот принцип является первым принципом, который применяется к интерфейсам вместо классов в SOLID, и он аналогичен принципу единой ответственности. В нем говорится, что « не заставляют клиентов реализовывать интерфейс, который не имеет к ним отношения ». Здесь ваша главная цель — сосредоточиться на том, чтобы избежать толстого интерфейса и отдать предпочтение множеству небольших клиентских интерфейсов. Вы должны предпочесть множество клиентских интерфейсов, а не один общий интерфейс, и каждый интерфейс должен иметь определенную ответственность.
Предположим, вы входите в ресторан и являетесь чистым вегетарианцем. Официант в этом ресторане дал вам карту меню, которая включает вегетарианские и невегетарианские блюда, напитки и сладости. В этом случае, как у клиента, у вас должна быть карточка меню, которая включает только вегетарианские блюда, а не все, что вы не едите в своей еде. Здесь меню должно быть разным для разных типов клиентов. Карту общего или общего меню для всех можно разделить на несколько карт вместо одной. Использование этого принципа помогает уменьшить побочные эффекты и частоту необходимых изменений.

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

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

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

This entry was posted in Популярное