SOLID — це набір із п'яти золотих правил у програмуванні, які допомагають писати код так, щоб його було легко читати, змінювати та підтримувати. Це як правила гігієни, але для коду: щоб він не "смердів" і не перетворився на заплутаний клубок (спагеті-код).
Ось пояснення кожного принципу простими словами та життєвими аналогіями.
Суть: Кожен клас, модуль чи функція повинні відповідати лише за щось одне.
Аналогія: Уявіть швейцарський ніж. У ньому є все: ніж, ножиці, пилка, викрутка. Але різати хліб ним незручно, крутити гвинти — теж так собі.
Як правильно: На кухні у вас є окремо ніж для хліба, окремо штопор і окремо викрутка в гаражі. Кожен інструмент робить свою роботу ідеально.
У коді: Не робіть "Клас-Бог", який і користувача реєструє, і звіти друкує, і листи відправляє. Розбийте це на три різні класи.
Суть: Програмні сутності мають бути відкриті для розширення, але закриті для змін.
Аналогія: Ви купили смартфон. Якщо ви хочете змінити його вигляд або захистити, ви вдягаєте чохол (розширюєте функціонал). Ви не розбираєте корпус і не перепаюєте плати, щоб змінити колір (не змінюєте початковий код).
У коді: Якщо вам треба додати нову функцію, ви повинні написати новий код, а не переписувати старий, який вже працює і протестований.
Суть: Об'єкти-спадкоємці повинні замінювати батьківські об'єкти без ламання програми.
Аналогія (Тест качки): Якщо щось виглядає як качка, крякає як качка, але потребує батарейок — це несправжня качка. Уявіть, що у вас є пульт від телевізора. Якщо ви купите новий пульт (спадкоємець), він має так само вмикати телевізор. Якщо новий пульт замість ввімкнення підриває телевізор — принцип порушено.
У коді: Клас-дитина не повинен ламати логіку, яку очікують від класа-батька.
Суть: Багато спеціалізованих інтерфейсів краще, ніж один універсальний. Клієнти не повинні залежати від методів, які вони не використовують.
Аналогія: Уявіть, що ви прийшли в ресторан купити каву, а вас змушують купити комплексний обід (борщ, салат, компот), бо в меню є тільки одна позиція — "Їжа".
Як правильно: Меню має бути розділене: напої окремо, десерти окремо. Ви платите тільки за те, що берете.
У коді: Не створюйте інтерфейси, де є методи летіти(), плавати() і бігати() одночасно. Бо якщо ви створите клас Риба, їй доведеться реалізувати метод летіти() (навіть порожній), а це неправильно.
Суть: Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Обидва повинні залежати від абстракцій.
Аналогія: Ви вмикаєте лампу в розетку. Лампі (модуль високого рівня) все одно, звідки береться струм: з АЕС, сонячної панелі чи генератора (модулі низького рівня). Вона залежить від стандартної вилки (абстракції/інтерфейсу). Якби лампа була "припаяна" напряму до проводки в стіні, ви б не змогли перенести її в іншу кімнату.
У коді: Ваш бізнес-код не повинен залежати напряму від конкретної бази даних (наприклад, MySQL). Він має залежати від абстракції "Сховище даних". Тоді ви зможете легко замінити MySQL на PostgreSQL без переписування всієї програми.
Дотримання SOLID робить ваш код схожим на конструктор LEGO:
Деталі легко замінювати.
Легко додавати нові кубики.
Конструкція не розвалюється, коли ви чіпаєте один елемент.
Бажаєте, я покажу приклад коду (наприклад, на Python або JavaScript) для якогось одного з цих принципів, щоб стало ще зрозуміліше?