SOLID-принципы: как писать код, который тебя не подведет

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

5 SOLID принципов, которые делают код хорошим

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

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

Эти правила написаны слезами программистов. Но в итоге позволяют следовать общим принципам. В программировании их можно сравнить с ПДД. Можно ли их нарушать? Да, но такие действия имеют последствия. А если не нарушать 5 принципов SOLID, то и проблем с кодом будет гораздо меньше.

Что такое SOLID? Это аббревиатура каждого из принципов. Давайте детальней с ними знакомиться.

S – Single Responsibility Principle

Объясним каждый принцип SOLID простым языком, без заумной терминологии. Первый — принцип единственной ответственности. Каждый класс в коде должен отвечать только за одну зону ответственности. Чтобы изменения в нем не влияли на другие части кода.

У вас есть нож. Он режет. Это его функция. Утюг гладит, а пылесос — пылесосит. Согласитесь, будет странно, если вы утюгом попробуете разрезать хлеб. При этом на утюге можно приготовить гренку. Но это не правильно. Наш «код» вроде работает, гренка готовится. Но запах сгоревшего хлеба на рубашке после глажки — не очень правильно. А все потому, что нарушен принцип единственной ответственности. 

O — Open Closed Principle

Следующий принцип SOLID — открытость и закрытость. Звучит так: класс должен быть открыт для расширения, но закрыт для изменения. Нельзя менять то, что уже работает. 

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

1. У вас есть интернет магазин, где нужно сделать функционал скидки.
2. Вы делаете скидку за регистрацию, для постоянных клиентов, при заказе от какой-то суммы. Но тут решаете добавить скидку в честь праздника.
3. Добавляете в файл с кодом условия. Если праздник, то давать такую-то скидку. Если день рождения, предлагать клиенту такую-то скидку. Если суббота — дает вот такую акцию. И таких «если» может быть очень много. Одна ошибка — и логика нарушается.
4. При соблюдении этого SOLID принципа создается система скидок. В уже внутри отдельными модулями делаются разные блоки. В каждом из которых свои условия. 

В таком случае, добавляя новые скидки, вы не сломаете существующую систему. Вероятность обнаружить «не состыковки» в коде возрастает. Работает принцип: добавляя новое, мы не ломаем старое.

L — Liskov Substitution Principle

Это принцип SOLID, который называется «Принцип подстановки Барбары Лисков». Эта женщина — гений информатики, ознакомьтесь с ее биографией. Принцип гласит следующее: если базовый класс заменить на наследника, то программа должна работать без изменений, потому что наследник перенимает всю логику базового класса.

Давайте проще. У вас есть кофемашина. Нажал кнопку — сварил кофе. Вам дают новую модель. Вы засыпаете кофе, нажимаете кнопку, а у вас льется суп. Не понимаете почему? Потому что это новая модель, которая умеет варить кофе и суп. Но вы же хотели только кофе… Вся проблема в том, что нарушены SOLID принципы. А именно: вы купили новую кофе машину, но ее поведение отличается от той, что у вас была.

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

I — Interface Segregation Principle

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

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

Удобно? С точки зрения логики — да. Все в одном месте. Но этот пульт имеет 128 кнопок. Телевизор вы не включали уже 2 года, кондиционер используется только летом, а как выглядит кнопка от микроволновки — вы и не знаете. 

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

D — Dependency Inversion Principle

Принцип SOLID звучит так: не нужно зависеть от конкретных деталей или интерфейсов. Лучше иметь зависимость от общих правил. 

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

Вернемся немного к IT. Вам нужно сделать блок оплаты в мобильном приложении. Но вы решаете подключить конкретную систему оплаты, например LiqPay. Тогда логика кода выглядит так:

1. Отправить платеж на LiqPay.
2. Получить статус оплаты от LiqPay.
3. Сохранить чек с LiqPay, перевести пользователя дальше.

Но тут компания решает подключить другую платежную систему. Stripe или PayPal. Вам придется переписать половину кода.

При соблюдении SOLID принципа инверсии зависимостей, логика выглядит иначе:

1. Принять платеж.
2. Подтвердить платеж.
3. Сохранить результат и перевести пользователя дальше.

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

Подпишитесь на наш Ютуб-канал! Полезные видео для программистов уже ждут вас! YouTube

Выберите свой курс! Путь к карьере программиста начинается здесь! Посмотреть

Заключение

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