Що таке SOLID?

Коротка шпаргалка по принципам S.O.L.I.D

• [S] Single Responsibility Principle (принцип єдиної відповідальності)

На кожен об'єкт має бути покладена одна єдина обов'язок

Модуль може мати одну і тільки одну причину для зміни. Для цього перевіряємо, скільки у нас є причин для зміни класу - якщо більше однієї, то слід розбити даний клас.

• [O] The Open / Closed Principle (принцип відкритості / закритості)

Класи і інші елементи повинні бути відкриті для розширення, але закриті для модифікації. На більш простих словах це можна описати так - все класи, функції і т.д. повинні проектуватися так, щоб для зміни їх поведінки, нам не потрібно було змінювати їх вихідний код. Для цього представляємо наш клас як «чорний ящик» і дивимося, чи можемо в такому разі змінити його поведінку.

• [L] The Liskov Substitution Principle (принцип підстановки Лісков)

Намагайтесь створювати підкласи таким чином, щоб їхні об’єкти можна було б підставляти замість базового класу, не ламаючи при цьому функціональність клієнтськогокоду.

Функції, які використовують базовий тип, повинні мати можливість використовувати підтипи базового типу, не знаючи про це. Або іншими словами, об'єкти в програмі можуть бути замінені їх наслідниками без зміни властивостей програми Для цього перевіряємо, не підсилили ми передумови і не послабили чи постумови. Якщо це сталося - то принцип не дотримується

• [I] The Interface Segregation Principle (принцип поділу інтерфейсу)

Багато спеціалізованих інтерфейсів краще, ніж один універсальний. Програмні суті не повинні залежати від методів, які вони не використовують. Дотримання цього принципу необхідно для того, щоб класи-клієнти використовуючи / реалізуючи інтерфейс знали тільки про ті методи, які вони використовують, що веде до зменшення кількості не використованого коду. Перевіряємо, наскільки багато інтерфейс містить методів і наскільки різні функції накладаються на ці методи, і якщо необхідно - розбиваємо інтерфейси.

• [D] The Dependency Inversion Principle (принцип інверсії залежностей)

Модулі верхніх рівнів не повинні залежати від модулів нижніх рівнів. Абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій

Коротше: Залежні компоненти повинні будується щодо абстракцій, а не деталей Перевіряємо, чи залежать класи від якихось інших класів (безпосередньо інстанціруют об'єкти інших класів і т.д) і якщо ця залежність має місце, замінюємо на залежність від абстракції