Перевод статьи от от Ugonna Thelma
Если вы знакомы с объектно-ориентированным программированием, тогда возможно вы слышали про SOLID принципы.
Эти пять принципов разработки программного обеспечения являются руководящими принципами, следуя им создается легко расшряемое и обслуживаемое ПО. Они стали популярны с помощью инженера программного обеспечения Robetra C. Martin.
Сейчас очень много статей в интернете про SOLID, но я редко вижу примеры с картинками. Как для меня это является немного сложным для визуального обучения, оставаясь вовлеченной в тему.
Итак главная цель этой статьи лучше понять эти принципы используя илюстрации и подчеркивая цель каждого принципа.
Ты увидишь, что некоторые принципы выглядят похожими но у них разные цели. Возможно удовлетворять одним принципам и нарушать другие, хотя они похожи.
Чтобы упростить понимание, я буду использовать Class, но заметь что это может быть функция, метод или модуль в этой статье.
Обновление*
Я получила некоторые комментарии про принцип открытости Закрытости в этой статье нарушает принцип единой ответственности. Пожалуйста обратите внимание, что цель этой статьи объяснить каждый принцип отдельно от остальных.
Также, ответственности(или роли) отличаются от Действий. В Принципе единой ответственности я использую «Я художник», в принципе открытости/закрытости я использую «Я могу рисовать».
На это важно обратить внимание, потому что некоторые действия могут заполнять ответственности (или роли). Класс должен иметь одну ответственность(принцип единой ответственности) но его функциональость которая аполняет его ответственности должа быть расширяема(Принцип открытости и закрытости)
Сейчас начнем!
SOLID принципы
S- Единая ответственность
Класс должен иметь отлько одну ответственность
Если класс имеет много ответственностей, это увеличивает возможность ошибок, потому что внося изменения в одну ответственность, можно повлиять на другие без вашего ведома.
Цель
Цель данного принципа разделить поведение, что даже если в результате возникнут ошибки, они не повлияли на другион несвязанное поведение.
. . .
O — Открытость и закрытость
Классы должны быть открыты для расширения и закрыты для модификации.
Изменение поведение текущего класса повлияет на все системы использующие этот класс.
Если ты хочет чтобы Класс выполнял больше функций, идеальный подход добавить новые функции к тем что уже есть а не изменять их.
Цель
Цель данного принципа расширять повередние Класса без внесение изменений в его существующее поведение. Это позволит избежать повления ошибок в то время когда Класс используется.
. . .
L — Подстановка Liskov
Если S это подтип T, тогда объекты типа Т в коде могут быть заменены объектами типа S без любых изменений свойств этого кода.
Когда дочерный класс не может выполнить теже операции что и его родительский класс, тогда мы может получать ошибки.
Когда у вас есть класс и затем создаем другой класс от него, он становится родительский и новый класс становится дочерним. Дочерний класс должен иметь возможность делать все что может его родительский класс. Этот процесс называется наследование.
Дочерний класс должен обрабатывать все теже запросы и досталвять тот же результат что и его родитель или может доставлять результат тогоже типа.
На картинке показано что родительский класс доставляет кофе(может быть любым типов кофе). Эта приемлемо для дочернего класса который доставляет капучино, потому что это конкретый тип кофе, но данное поведение не возможно для доставки воды.
. . .
Цель
I — Разделение инферфейса
Клиенты не должы быть зависимыми от методов которые ои не используют.
Когда класс требует предоставления всех действий которые не использует. это расточительно и может привести к неожиданным багам если класс не способен выполнить это действия.
Класс должен выполнять только те действия, которые нужны для выполнения его роли. Любый другие действия должы быть удалены полностью или перемещены в другое место(Класс) где они можут быть использованы в будущем.
Цель
Цель принципа расщепить больие наборы действий на маленькие, в которых нуждает класс.
. . .
D — Инверсия зависимостей
- Более высокий ровень модуля не должен зависет от нижних модулей. Оба должы зависеть от обстракций
- Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций
Перонаперво, давайте определим названия для более простого использования.
Высокий уровеньь модуля(Класса): Класс который выполняет действия с инструментом
Нижний уровень модуля(Класса): Инструменты которые нужны для выполнения действий
Абстракция: Представляет интерфейс который соединяет два класса
Детали: Как работают инструменты
Этот принцип говорит что класс не должен слвиватся с инструментацми которые он использует для выполнения действий. Скорее, он должен сливаться с интерфейсм который разрешение в инструмета для соединения с классом.
Это тагже говорит нам, что оба класса и интерфейс недолжны знать как работают инструмента. Однаком инструменты должны меть конкретику из интерфейса.
Цель
Цель принципа это сокращеие зависимостей Класса верхнего уровня от класса ижего уровя по средствам интерфейса.
. . .
В Итоге
Итак, только что мы обсдули пять принципов и выделили их цели. Они помогают нам сделать код более гибкий, расширяемый и тестируемый без каких либо проблем.
Большое спасибо за чтение. Я надеюсь у вас появятся идеи об этом и вы получили удовольствие в чтении того что я написала.
Если у вас есть любый вопросы или предложения, оставляйте комметарий.
