Щоб програма або застосунок добре працювали і виконували своє призначення, код повинен бути грамотним, «чистим» і не мати логічних порушень. Для цього програмісту слід дотримуватися певних правил. Найправильніше рішення — використовувати SOLID принципи. Про них і поговоримо.
5 SOLID принципів, які роблять код хорошим
SOLID принципи — це набір правил створення коду, які допомагають розробникам дотримуватися єдиної логіки. Вони потрібні, щоб:
- легко масштабувати код;
- швидко знаходити потрібні складові;
- коректно вносити зміни;
- працювати з кодом іншим фахівцям;
- відстежувати баги, помилки;
- підтримувати працездатність.
Ці правила написані сльозами програмістів. Але в підсумку дозволяють дотримуватися загальних принципів. У програмуванні їх можна порівняти з ПДР. Чи можна їх порушувати? Так, але такі дії мають наслідки. А якщо не порушувати 5 принципів SOLID, то і проблем з кодом буде набагато менше.
Що таке SOLID? Це абревіатура кожного з принципів. Давайте детальніше з ними ознайомимося.
S – Single Responsibility Principle
Пояснимо кожен принцип SOLID простою мовою, без заумної термінології. Перший — принцип єдиної відповідальності. Кожен клас у коді повинен відповідати тільки за одну зону відповідальності. Щоб зміни в ньому не впливали на інші частини коду.
У вас є ніж. Він ріже. Це його функція. Праска прасує, а пилотяг — пилотяжить. Погодьтеся, буде дивно, якщо ви праскою спробуєте розрізати хліб. При цьому на прасці можна приготувати грінку. Але це не правильно. Наш «код» нібито працює, грінка готується. Але запах згорілого хліба на сорочці після прасування — не дуже правильно. А все тому, що порушено принцип єдиної відповідальності.
O — Open Closed Principle
Наступний принцип SOLID — відкритість і закритість. Звучить так: клас повинен бути відкритий для розширення, але закритий для зміни. Не можна змінювати те, що вже працює.
Наприклад, у вас є ігрова приставка. Ви хочете додати нову гру. Для цього потрібно вставити інший диск в приставку, а не брати в руки паяльник і перепаювати схеми всередині неї. Як принцип SOLID працює в Digital:
- У вас є інтернет-магазин, де потрібно зробити функціонал знижки.
- Ви робите знижку за реєстрацію, для постійних клієнтів, при замовленні від певної суми. Але тут вирішуєте додати знижку на честь свята.
- Додаєте в файл з кодом умови. Якщо свято, то давати таку-то знижку. Якщо день народження, пропонувати клієнту таку-то знижку. Якщо субота — дає ось таку акцію. І таких «якщо» може бути дуже багато. Одна помилка — і логіка порушується.
При дотриманні цього SOLID принципу створюється система знижок. Уже всередині окремими модулями робляться різні блоки. У кожному з яких свої умови.
У такому випадку, додаючи нові знижки, ви не зламаєте чинну систему. Імовірність виявити «нестикування» в коді зростає. Працює принцип: додаючи нове, ми не ламаємо старе.
L — Liskov Substitution Principle
Це принцип SOLID, який називається «Принцип підстановки Барбари Лісков». Ця жінка — геній інформатики, ознайомтеся з її біографією. Принцип говорить наступне: якщо базовий клас замінити на спадкоємця, то програма повинна працювати без змін, тому що спадкоємець переймає всю логіку базового класу.
Давайте простіше. У вас є кавоварка. Натиснув кнопку — зварив каву. Вам дають нову модель. Ви засипаєте каву, натискаєте кнопку, а у вас ллється суп. Не розумієте чому? Тому що це нова модель, яка вміє варити каву і суп. Але ви ж хотіли тільки каву… Вся проблема в тому, що порушені SOLID принципи. А саме: ви купили нову кавоварку, але її поведінка відрізняється від тієї, що у вас була.
Коли ж принцип дотриманий? Коли нова кавоварка, як і раніше, варить тільки каву, але здатна спінювати молоко або перемелювати зерна. Тому що додавання цих функцій не вплинуло на її основу — вміння варити каву, а не суп.
I — Interface Segregation Principle
Цей принцип SOLID говорить: великі інтерфейси потрібно розбивати на менші, щоб зменшити залежності між елементами.
Користувач не повинен залежати від інтерфейсів, які він не використовує. Уявімо, що у вас є універсальний пульт від усього будинку. Він і світло вмикає, і пральну машинку, і піч. А ще з його допомогою можна регулювати кондиціонер, відкривати жалюзі та, звичайно, керувати телевізором.
Зручно? З погляду логіки — так. Все в одному місці. Але цей пульт має 128 кнопок. Телевізор ви не вмикали вже 2 роки, кондиціонер використовується тільки влітку, а як виглядає кнопка від мікрохвильовки — ви й не знаєте.
Погодьтеся, краще мати багато маленьких пультів під кожен пристрій. Використовувати той, який потрібен наразі. А якщо загубиться пульт від кондиціонера, то це не завадить вам увімкнути телевізор.
D — Dependency Inversion Principle
Принцип SOLID звучить так: не потрібно залежати від конкретних деталей або інтерфейсів. Краще мати залежність від загальних правил.
Знову ж таки, на прикладі пульта. Добре, коли один пульт підходить до різних моделей телевізора. Не потрібно думати, як під цю модель підібрати пульт. Досить взяти «стандартний».
Повернемося трохи до IT. Вам потрібно зробити блок оплати в мобільному застосунку. Але ви вирішуєте підключити конкретну систему оплати, наприклад LiqPay. Тоді логіка коду виглядає так:
- Відправити платіж на LiqPay.
- Отримати статус оплати від LiqPay.
- Зберегти чек з LiqPay, перевести користувача далі.
Але тут компанія вирішує підключити іншу платіжну систему. Stripe або PayPal. Вам доведеться переписати половину коду.
При дотриманні SOLID принципу інверсії залежностей, логіка виглядає інакше:
- Прийняти платіж.
- Підтвердити платіж.
- Зберегти результат і перевести користувача далі.
А далі готується реалізація. На цьому етапі підключається потрібний сервіс. І якщо буде необхідність замінити сервіс, то доведеться залазити тільки в цю частину, а не в саму логіку роботи системи оплати.
YouTube
Висновок
Тепер ви знаєте SOLID принципи. В ООП вони регулярно використовуються. На жаль, як і автомобілісти за кермом, розробники теж порушують їх і не завжди дотримуються правил. Але якщо ви будете слідувати їм, то ваш код буде завжди зрозумілим, красивим, масштабованим, а головне — робочим.
