🛠️ SOLID: Почему важно соблюдать принципы?



Сегодня поговорим о SOLID – пяти принципах, которые делают код понятным, гибким и легким для поддержки. Если ты хочешь писать код, который не треснет по швам через пару месяцев, эти принципы — твои лучшие друзья.

1. Single Responsibility Principle (SRP)
Одна ответственность – один класс.
Если у класса больше одной причины измениться, значит, он нарушает SRP. Такой код сложно поддерживать, потому что при изменении одной логики мы можем случайно сломать другую.

✅ Правильно:
class ReportGenerator {
void generateReport() { /* Логика генерации отчета */ }
}

class ReportSaver {
void saveReport() { /* Логика сохранения отчета */ }
}


❌ Неправильно (всё в одном месте):
class ReportService {
void generateAndSaveReport() { /* Генерация + сохранение отчета */ }
}


2. Open/Closed Principle (OCP)
Код открыт для расширения, но закрыт для модификации.
Когда нам нужно добавить новую функциональность, мы должны расширять существующий код, а не менять его.

✅ Пример с интерфейсом:
interface Payment {
void process();
}

class CreditCardPayment implements Payment {
public void process() { /* Логика оплаты картой */ }
}

class PayPalPayment implements Payment {
public void process() { /* Логика оплаты PayPal */ }
}

Теперь мы можем добавить новый способ оплаты, просто создав новый класс.

3. Liskov Substitution Principle (LSP)
Дочерние классы должны полностью заменять родительские.
Если где-то используется родительский класс, мы должны без проблем подставить его потомка.

❌ Нарушение LSP:
class Bird {
void fly() { /* Летает */ }
}

class Penguin extends Bird {
void fly() { throw new UnsupportedOperationException("Пингвины не летают!"); }
}


Проблема в том, что Penguin нарушает контракт родителя.

✅ Используем интерфейсы:
interface Bird { }
interface FlyingBird extends Bird { void fly(); }

class Sparrow implements FlyingBird {
public void fly() { /* Летает */ }
}

class Penguin implements Bird {
// Пингвин вообще не имеет метода fly()
}


4. Interface Segregation Principle (ISP)
Лучше несколько маленьких интерфейсов, чем один большой.

❌ Плохой пример:
interface Worker {
void work();
void eat();
}

class Robot implements Worker {
public void work() { /* Работает */ }
public void eat() { throw new UnsupportedOperationException("Роботы не едят!"); }
}

✅ Разделяем интерфейсы:
interface Workable {
void work();
}

interface Eatable {
void eat();
}

class Robot implements Workable {
public void work() { /* Работает */ }
}


5. Dependency Inversion Principle (DIP)
Модули верхнего уровня не должны зависеть от модулей нижнего уровня.
Оба должны зависеть от абстракций.

❌ Жёсткая зависимость:
class Lamp {
void turnOn() { /* Включить */ }
}

class Switch {
private Lamp lamp;

Switch(Lamp lamp) {
this.lamp = lamp;
}

void press() { lamp.turnOn(); }
}


✅ Используем абстракции:
interface Switchable {
void turnOn();
}

class Lamp implements Switchable {
public void turnOn() { /* Включить */ }
}

class Switch {
private Switchable device;

Switch(Switchable device) {
this.device = device;
}

void press() { device.turnOn(); }
}

📌 Итог
Принципы SOLID помогают писать гибкий, поддерживаемый и расширяемый код. Если следовать этим принципам, код будет легче читать и рефакторить.

👉 @BookJava
Просмотры: 982
Открыть в MAX Сообщить о неточности

Репосты публикации

Публикация канала

Сообщить о неточности

Опишите, что нужно исправить. Если есть источник, добавьте ссылку.

Вы покидаете datool.ru

Ссылка ведёт на внешний сайт. datool.ru не отвечает за его содержимое — проверьте адрес, прежде чем вводить пароли или платёжные данные.

Переход через 10 с

Перейти