Skip to content

solid.md

Latest commit

 

History

History
48 lines (35 loc) · 4.13 KB

solid.md

File metadata and controls

48 lines (35 loc) · 4.13 KB

Solid

  • SRP - single responsibility principle.
  • OCP - Open / Close principle.
  • LSP - Liskov substitution principle.
  • ISP - Interface segregation principle.
  • DIP - Dependency inversion principle.

Code Smell - ознаки поганого коду

  • Rigidity - Ригідність, висока ціна внесення однієї зміни.
  • Fragility - Крихкість, невеликі зміни в одному модулі викликають помилки у інших модулях.
  • Immobility - Нерухомість, компоненти не можна використати повторно в інших системах.
  • Viscosity - В'язкість, додавання однієї фічі викликає необхідність робиратись з багатьма аспектами.

SRP - single responsibility principle

Принцип єдиної відповідальності - кожен об'єкт повинен мати єдину відповідальність, і ця відповідальність повинна бути інкапсульованою класом. Простіше кажучи, один клас має робити щось одне.

Використання SRP веде до появи багатьох маленьких класів, між якими буває складно розібратись.

Прикладом SRP є використання патерну Фасад, де у класу є лише одна відповідальність - забезпечити простий інтерфейс для клієнта.

OCP - Open / Close principle

Елементи системи мають бути відкриті для розширення, але закриті для змін. Потрібно мати можливість вносити зміни додаючи новий код, а не змінюючи існуючий.

Паттерн Декоратор є прикладом застосування OCP, де паттерн додає нову поведінку до об'єкту без зміни оригінального коду.

LSP - Liskov substitution principle

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

Простішими словами: батьківський клас можна замінити на дочірній без зміни властивостей програми.

ISP Interface segregation principle

Клієнти не повинні залежати від методів, які вони не використовують. Або, в інтерфейсі повинні бути лише методи пов'язані з конкретною задачею.

DIP - dependency inversion principle.

Dependency Inversion Diagram Високорівневі модулі не повинні (на пряму) залежати від низькорівневих. Обидва типи модулів повинні залежати від абстракцій (інтерфейсів та абстрактних клас). Високорівнева політика не повинна залежати від низькорівневих деталей.

По простому, між високорівневими та низькорівневими модулями має бути інтерфейс.

Прикладом DIP є паттерн Фабричний метод, який дозволяє створювати об'єкти через інтерфейс, а не напряму.