DRY
- Дублювання коду – марна трата часу та ресурсів. Вам доведеться підтримувати ту саму логіку і тестувати код відразу в двох місцях, причому якщо ви зміните код в одному місці, його потрібно буде змінити і в іншому.
KISS
- Принцип KISS - це коли ви берете завдання і вирішуєте його простим способом:
- Не підключаєте всю бібліотеку, якщо потрібна всього кілька функцій.
- Не закладаєте надлишкових функцій, якщо про них не просив замовник.
- Не використовуєте надлишкові класи та методи.
- Чи не перевантажуєте інтерфейс і не робите складну бізнес-логіку.
- Не виконуєте інші дії, якщо вони не впливають на роботу проектів
- Стосовно розробки ПЗ він означає наступне - не вигадуйте до завдання складнішого рішення, ніж їй потрібно
SOLID
S – Single Responsibility Principle – принцип єдиної відповідальності.
L - Liskov substitution Principle - принцип підстановки Барбари Лисков.
Його важливість неможливо переоцінити. Кожен об'єкт, клас та метод повинні відповідати лише за щось одне. Якщо ваш об'єкт/клас/метод робить занадто багато, ви отримаєте спагетті-код. Ще один побічний ефект такого коду – проблеми з тестуванням. Заплутаний функціонал тестувати складно. O – Open closed Principle – принцип відкритості-закритості.
Програмні об'єкти мають бути відкриті для розширення, але закриті для модифікації. Йдеться про те, що не можна перевизначати методи чи класи, просто додаючи додаткові функції за необхідності.
Цей принцип свідчить, що об'єкти старших класів мають бути замінні об'єктами підкласів, і додаток за такої заміни має працювати так, як очікується. Принцип підстановки Барбари Лисков полягає у правильному використанні відносини спадкування. Ми повинні створювати спадкоємців якогось базового класу тоді і лише тоді, коли вони збираються правильно реалізувати його логіку, не викликаючи проблем при заміні батьків на спадкоємців I - Interface Segregation Principle – принцип поділу інтерфейсів.
Об'єкти не повинні залежати від інтерфейсів, які вони не використовують
ПЗ має поділятися на незалежні частини. Побічні ефекти необхідно зводити до мінімуму, щоб забезпечити незалежність.
Переконайтеся, що ви не змушуєте об'єкти реалізовувати методи, які їм ніколи не знадобляться.
D – Dependency Inversion Principle – принцип інверсії залежностей.
Цей принцип неможливо переоцінити. Ми маємо покладатися на абстракції, а не на конкретні реалізації. Компоненти ПЗ повинні мати низьку зв'язність та високу узгодженість.
Дбати потрібно не про те, як щось влаштовано, а про те, як воно працює.