Что такое Dependency Injection (DI) и как оно связано с #solid?

**Принцип разделения интерфейса** гласит:
> Клиенты не должны зависеть от методов, которые они не используют.

Простыми словами: лучше создать **много маленьких, специализированных интерфейсов**, чем один огромный и универсальный («толстый»). Когда интерфейс слишком большой, классы, которые его реализуют, вынуждены писать пустые методы-заглушки для функций, которые им на самом деле не нужны.

---

## ❌ Нарушение принципа (плохой код)

Представьте, что мы создаем интерфейс для умных устройств `SmartDevice`. У нас есть навороченный принтер (который умеет всё) и старый черно-белый принтер (который умеет только печатать).

```typescript
// Огромный "толстый" интерфейс
interface SmartDevice {
  print(): void;
  scan(): void;
  fax(): void;
}

// Навороченный офисный принтер — ему всё подходит
class AllInOnePrinter implements SmartDevice {
  public print() { console.log("Печать документа..."); }
  public scan() { console.log("Сканирование..."); }
  public fax() { console.log("Отправка факса..."); }
}

// Простой принтер на складе — нарушает ISP
class OldPrinter implements SmartDevice {
  public print() {
    console.log("Печать документа...");
  }

  // Нарушение ISP: класс вынужден реализовывать методы, которые он не поддерживает!
  public scan() {
    throw new Error("Я старый принтер, я не умею сканировать!");
  }

  public fax() {
    throw new Error("У меня нет факса!");
  }
}
```

*Почему это плохо?* Класс `OldPrinter` зависит от функций `scan` и `fax`, которых у него физически нет. Если мы случайно вызовем эти методы в коде, программа упадет с ошибкой.

---

## ✅ Соблюдение принципа (хороший код)

Мы разделяем один большой интерфейс на три маленьких и независимых. Теперь каждый класс берет (реализует) только то, что ему действительно нужно для работы.

### 1. Создаем маленькие специализированные интерфейсы

```typescript
interface Printer {
  print(): void;
}

interface Scanner {
  scan(): void;
}

interface Fax {
  fax(): void;
}
```

### 2. Реализуем классы без лишнего кода

Благодаря TypeScript, один класс может реализовывать сразу несколько интерфейсов через запятую.

```typescript
// Старый принтер берет только интерфейс Printer
class OldPrinter implements Printer {
  public print() {
    console.log("Печать документа на старом принтере...");
  }
}

// Современный комбайн реализует ВСЕ интерфейсы разом
class AllInOnePrinter implements Printer, Scanner, Fax {
  public print() { console.log("Печать..."); }
  public scan() { console.log("Сканирование..."); }
  public fax() { console.log("Отправка факса..."); }
}
```

### 3. Безопасное использование

Теперь функции, работающие с устройствами, точно знают, на что способен объект.

```typescript
// Функция принимает только то устройство, которое ГАРАНТИРОВАННО умеет сканировать
function processDocument(scanner: Scanner) {
  scanner.scan();
}

const superPrinter = new AllInOnePrinter();
const oldPrinter = new OldPrinter();

processDocument(superPrinter); // Всё отлично работает!
// processDocument(oldPrinter);  // Ошибка TypeScript! Мы даже не сможем скомпилировать этот код, защитив себя от багов в рантайме.
```

---

### В чем выгода ISP?
1. **Безопасность типов**: Вы никогда не вызовете несуществующий метод у объекта, так как TypeScript подсветит ошибку еще на этапе написания кода.
2. **Гибкость**: Код становится модульным. Классы не перегружены логикой «на всякий случай».
3. **Чистота**: Отсутствуют пустые методы-заглушки со строками `return null` или `throw new Error()`.

#solid [I] Принцип разделения интерфейса (Interface Segregation Principle — ISP)

**Принцип подстановки Барбары Лисков** гласит:
> Объекты в программе должны быть заменяемыми на экземпляры их подклассов без изменения правильности работы программы.

Простыми словами: класс-наследник (дочерний класс) должен расширять поведение базового класса (родителя), но **ни в коем случае не ломать его**. Если вы вместо родительского класса передадите в функцию любой из его подклассов, программа должна продолжить работать корректно и без ошибок.

---

## ❌ Нарушение принципа (плохой код)

Классический пример нарушения LSP — это классическая геометрическая задача с квадратом и прямоугольником. С точки зрения математики квадрат — это прямоугольник. Но в программировании наследование квадрата от прямоугольника ломает логику.

```typescript
class Rectangle {
  constructor(protected width: number, protected height: number) {}

  public setWidth(width: number) { this.width = width; }
  public setHeight(height: number) { this.height = height; }
  
  public getArea(): number {
    return this.width * this.height;
  }
}

// Квадрат наследуется от Прямоугольника
class Square extends Rectangle {
  // Нарушение LSP: Квадрат вынужден менять поведение родительских методов,
  // так как у него стороны должны быть равны. Изменение одной стороны меняет обе.
  public setWidth(width: number) {
    this.width = width;
    this.height = width;
  }

  public setHeight(height: number) {
    this.width = height;
    this.height = height;
  }
}

// Функция, которая ожидает Прямоугольник
function renderArea(rectangle: Rectangle) {
  rectangle.setWidth(4);
  rectangle.setHeight(5);
  
  // Для ЛЮБОГО прямоугольника площадь 4 * 5 должна быть 20.
  console.log(`Ожидаемая площадь: 20, Реальная: ${rectangle.getArea()}`);
}

// Использование:
renderArea(new Rectangle(0, 0)); // Выведет 20. Всё супер!
renderArea(new Square(0, 0));    // Выведет 25! Логика функции сломалась из-за подкласса.
```

*Почему это плохо?* Разработчик функции `renderArea` рассчитывает на стандартное поведение прямоугольника. Но подкласс `Square` неожиданно изменил правила игры, нарушив контракт родительского класса.

---

##  ✅ Соблюдение принципа (хороший код)

Квадрат и прямоугольник — это разные фигуры со своими правилами. Вместо того чтобы наследовать их друг от друга, их нужно объединить под общей абстракцией (интерфейсом) `Shape`, где у каждого будет своя независимая реализация подсчета площади.

### 1. Создаем интерфейс для всех фигур

```typescript
interface Shape {
  getArea(): number;
}
```

### 2. Создаем независимые классы

```typescript
class Rectangle implements Shape {
  constructor(private width: number, private height: number) {}

  public setWidth(width: number) { this.width = width; }
  public setHeight(height: number) { this.height = height; }

  public getArea(): number {
    return this.width * this.height;
  }
}

class Square implements Shape {
  constructor(private size: number) {}

  public setSize(size: number) { this.size = size; }

  public getArea(): number {
    return this.size * this.size;
  }
}
```

### 3. Используем полиморфизм без скрытых багов

Теперь функция работает с абстракцией `Shape`. Мы можем передать туда и `Rectangle`, и `Square` — они гарантированно вернут правильную площадь, не ломая ожидания разработчика.

```typescript
function printArea(shape: Shape) {
  // Функция просто просит фигуру посчитать площадь. Никаких скрытых сюрпризов.
  console.log(`Площадь фигуры: ${shape.getArea()}`);
}

// Использование:
const rect = new Rectangle(4, 5);
const square = new Square(5);

printArea(rect);   // Выведет: 20
printArea(square); // Выведет: 25
```

---

### Как понять, что вы нарушаете LSP?
1. В дочернем классе есть методы, которые выбрасывают ошибку вроде `throw new Error("Этот метод не поддерживается")`.
2. Дочерний класс полностью игнорирует или зануляет логику родительского метода.
3. Вам приходится использовать проверку типов (`if (figura instanceof Square)`) внутри функций, которые работают с родительским классом.

#solid [L] Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP)

**Принцип открытости/закрытости** гласит:
> Программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.

Это значит, что если вам нужно добавить в программу новую логику или новые возможности, вы должны делать это путем **добавления нового кода**, а не изменением уже существующего, протестированного и работающего.

---

## ❌ Нарушение принципа (плохой код)

Представьте, что у нас есть класс для расчета стоимости доставки. Изначально мы доставляем только на машинах (`Car`). Но бизнес растет, и нам нужно добавить доставку на самолете (`Air`).

Чтобы это сделать, нам приходится заходить внутрь рабочего класса `ShippingCalculator` и менять конструкцию `if/else` или `switch`. 

```typescript
class ShippingCalculator {
  // Нарушение OCP: каждый раз при добавлении нового типа доставки 
  // нам придется модифицировать этот метод и этот класс.
  public calculateCost(type: string, weight: number): number {
    if (type === 'Car') {
      return weight * 5; // 5 рублей за кг
    } else if (type === 'Train') {
      return weight * 3; // 3 рубля за кг
    } else if (type === 'Air') {
      return weight * 20; // 20 рублей за кг (пришлось дописать код!)
    }
    
    throw new Error('Неизвестный тип доставки');
  }
}

// Использование
const calculator = new ShippingCalculator();
console.log(calculator.calculateCost('Car', 10)); // 50
```
*Почему это плохо?* Если мы случайно ошибемся при редактировании этого файла, мы можем сломать расчет для старых типов доставки (`Car` или `Train`), которые уже давно успешно работают.

---

##  ✅ Соблюдение принципа (хороший код)

Чтобы соблюсти OCP, мы создаем **интерфейс** (абстракцию) для всех видов доставки. Теперь каждый новый тип доставки будет отдельным классом. Класс-калькулятор станет «закрыт» от изменений, но «открыт» для расширения за счет полиморфизма.

### 1. Создаем интерфейс для доставки

```typescript
interface DeliveryMethod {
  getCost(weight: number): number;
}
```

### 2. Реализуем конкретные типы доставки как отдельные классы

```typescript
class CarDelivery implements DeliveryMethod {
  public getCost(weight: number): number {
    return weight * 5;
  }
}

class TrainDelivery implements DeliveryMethod {
  public getCost(weight: number): number {
    return weight * 3;
  }
}

// Новая фича: Доставка самолетом. Создаем НОВЫЙ класс, не трогая старый код!
class AirDelivery implements DeliveryMethod {
  public getCost(weight: number): number {
    return weight * 20;
  }
}
```

### 3. Класс калькулятора (Закрыт для модификации)

Теперь `ShippingCalculator` принимает любой объект, реализующий интерфейс `DeliveryMethod`. Ему не важно, какой именно транспорт используется — код этого класса больше **никогда не изменится**, сколько бы новых видов транспорта мы ни добавили.

```typescript
class ShippingCalculator {
  // Метод принимает абстракцию, а не конкретный тип
  public calculateCost(delivery: DeliveryMethod, weight: number): number {
    return delivery.getCost(weight);
  }
}

// Использование:
const calculator = new ShippingCalculator();

const car = new CarDelivery();
const air = new AirDelivery();

console.log(calculator.calculateCost(car, 10)); // 50 (Доставка машиной)
console.log(calculator.calculateCost(air, 10)); // 200 (Доставка самолетом)
```

---

### В чем выгода OCP?
1. **Безопасность**: Старый код не редактируется, а значит, риск внести новые баги в уже работающие фичи равен нулю.
2. **Масштабируемость**: Если завтра добавится доставка дронами, курьером или ракетой — мы просто напишем новые классы (`DroneDelivery`, `CourierDelivery`), реализующие интерфейс `DeliveryMethod`.
3. **Легкость тестирования**: Новые классы тестируются отдельно, старые тесты переписывать не нужно.

#solid [O] Принцип открытости/закрытости (Open-Closed Principle — OCP)

**Принцип единственной ответственности** гласит:
> У каждого класса должна быть только одна причина для изменения.

Это означает, что класс должен решать ровно **одну конкретную задачу**. Если класс делает слишком много разнородных вещей (работает с базой данных, шлет письма, форматирует текст), его становится тяжело тестировать, изменять и поддерживать. Изменение одной функции может случайно сломать другую.

---

## ❌ Нарушение принципа (плохой код)

В этом примере один класс `OrderManager` делает абсолютно всё: считает стоимость, имитирует сохранение в базу данных, отправляет email и пишет логи. 

```typescript
class OrderManager {
  public createOrder(orderId: string, items: any[]) {
    // 1. Бизнес-логика: подсчет стоимости
    const total = items.reduce((sum, item) => sum + item.price, 0);
    console.log(`Заказ ${orderId} создан. Сумма: ${total} руб.`);

    // 2. Нарушение SRP: Работа с базой данных
    console.log(`Сохранение заказа ${orderId} в базу данных...`);

    // 3. Нарушение SRP: Отправка уведомлений
    console.log(`Отправка Email: Ваш заказ ${orderId} успешно оформлен!`);

    // 4. Нарушение SRP: Логирование
    console.log(`[LOG] Заказ ${orderId} обработан в ${new Date().toISOString()}`);
  }
}

// Использование:
const manager = new OrderManager();
manager.createOrder("101", [{ price: 500 }, { price: 1500 }]);
```

---

##  ✅ Соблюдение принципа (хороший код)

Мы разделяем обязанности. Создаем отдельные специализированные классы для базы данных, уведомлений и логирования. Класс `OrderService` теперь отвечает только за управление процессом (бизнес-логику).

### 1. Выносим отдельные ответственности в свои классы

```typescript
// Класс отвечает ТОЛЬКО за сохранение данных
class OrderRepository {
  public save(orderId: string): void {
    console.log(`Сохранение заказа ${orderId} в базу данных...`);
  }
}

// Класс отвечает ТОЛЬКО за отправку сообщений
class EmailNotification {
  public sendConfirmation(orderId: string): void {
    console.log(`Отправка Email: Ваш заказ ${orderId} успешно оформлен!`);
  }
}

// Класс отвечает ТОЛЬКО за логирование
class Logger {
  public info(message: string): void {
    console.log(`[LOG] ${message} в ${new Date().toISOString()}`);
  }
}
```

### 2. Собираем всё в главном сервисе управления заказами

Теперь `OrderService` получает нужные инструменты через конструктор и просто координирует их работу.

```typescript
class OrderService {
  constructor(
    private repository: OrderRepository,
    private notification: EmailNotification,
    private logger: Logger
  ) {}

  public createOrder(orderId: string, items: any[]): void {
    // Чистая бизнес-логика (расчет стоимости)
    const total = items.reduce((sum, item) => sum + item.price, 0);
    console.log(`Заказ ${orderId} создан. Сумма: ${total} руб.`);

    // Делегируем задачи другим классам
    this.repository.save(orderId);
    this.notification.sendConfirmation(orderId);
    this.logger.info(`Заказ ${orderId} успешно обработан`);
  }
}

// Использование:
// 1. Создаем экземпляры вспомогательных классов
const repo = new OrderRepository();
const mailer = new EmailNotification();
const logger = new Logger();

// 2. Передаем их в главный сервис (Внедрение зависимостей вручную)
const orderService = new OrderService(repo, mailer, logger);
orderService.createOrder("102", [{ price: 300 }, { price: 700 }]);
```

---

### В чем выгода такого разделения?
1. **Легко читать**: Каждый класс маленький, его код понятен с первого взгляда.
2. **Легко менять**: Если завтра вместо Email нужно будет отправлять SMS, мы изменим только класс `EmailNotification` (или заменим его на `SmsNotification`), а код подсчета стоимости заказов останется нетронутым.
3. **Повторное использование**: Класс `Logger` или `EmailNotification` теперь можно использовать в других частях программы (например, при регистрации пользователей), не копируя код.

#solid [S] Принцип единственной ответственности (Single Responsibility Principle — SRP)

**Принцип инверсии зависимостей** гласит:
> 1️⃣ Модули верхнего уровня (бизнес-логика) не должны зависеть от модулей нижнего уровня (детали реализации, такие как конкретные базы данных, API или файловая система). Оба типа модулей должны зависеть от абстракций.
> &nbsp;
> 2️⃣ Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Простыми словами: ваш главный код должен управлять инструментами через **интерфейсы**, а не привязываться к конкретным классам жестко.

---

## ❌ Нарушение принципа (плохой код)

В этом примере класс бизнес-логики `NotificationManager` (верхний уровень) напрямую зависит от конкретного класса `SmsService` (нижний уровень). Если мы решим отправлять уведомления через Email, нам придется переписывать код `NotificationManager`.

```typescript
// Нижний уровень (Деталь реализации)
class SmsService {
  public sendSms(phone: string, text: string) {
    console.log(`[SMS] Отправлено на ${phone}: ${text}`);
  }
}

// Верхний уровень (Бизнес-логика)
class NotificationManager {
  private smsService: SmsService;

  constructor() {
    // ЖЕСТКАЯ СВЯЗЬ: класс сам создает экземпляр конкретного SMS-сервиса
    this.smsService = new SmsService();
  }

  public notifyUser(message: string) {
    // Мы жестко привязаны к отправке именно SMS
    this.smsService.sendSms("+79991112233", message);
  }
}

// Использование
const manager = new NotificationManager();
manager.notifyUser("Привет!");
```

---

##  ✅ Соблюдение принципа (хороший код)

Мы «выворачиваем» (инвертируем) зависимость. Создаем **интерфейс** `MessageSender` (абстракцию). Теперь наша бизнес-логика зависит только от этого интерфейса. Сам инструмент отправки передается (внедряется) снаружи через конструктор.

### 1. Создаем абстракцию (Интерфейс)

```typescript
interface MessageSender {
  sendMessage(text: string): void;
}
```

### 2. Создаем разные детали реализации

```typescript
class SmsSender implements MessageSender {
  public sendMessage(text: string): void {
    console.log(`[SMS] Отправлено: ${text}`);
  }
}

class EmailSender implements MessageSender {
  public sendMessage(text: string): void {
    console.log(`[Email] Отправлено: ${text}`);
  }
}
```

### 3. Класс бизнес-логики (Зависит только от абстракции)

Код `NotificationManager` стал чистым. Он понятия не имеет, как технически отправляется сообщение — по воздуху, по проводам или почтовым голубем. Он просто знает, что у объекта есть метод `sendMessage`.

```typescript
class NotificationManager {
  // Зависимость от ИНТЕРФЕЙСА, а не от конкретного класса
  constructor(private sender: MessageSender) {}

  public notifyUser(message: string) {
    this.sender.sendMessage(message);
  }
}

// Использование (Клиентский код)
const sms = new SmsSender();
const email = new EmailSender();

// Мы можем легко менять способ отправки, вообще не трогая код NotificationManager:
const smsNotification = new NotificationManager(sms);
smsNotification.notifyUser("Ваш код: 4422");

const emailNotification = new NotificationManager(email);
emailNotification.notifyUser("Добро пожаловать на сайт!");
```

---

### В чем выгода DIP?
1. **Слабая связанность (Loose Coupling)**: Модули изолированы друг от друга. Изменения в одном классе не ломают другие.
2. **Легкое тестирование**: В тестах вместо реальной отправки SMS или запросов к базе данных вы можете передать фейковый объект-заглушку (Mock), который просто реализует нужный интерфейс.
3. **Готовность к изменениям**: Замена одной технологии на другую (например, переход со старой СУБД на новую) происходит безболезненно.

#solid [D] Принцип инверсии зависимостей (Dependency Inversion Principle — DIP)

# [SOLID](https://ru.m.wikipedia.org/wiki/SOLID_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5))

<CollapsibleBox
header="SRP: Single Responsibility Principle"
text="### Принцип единственной ответственности
Любой модуль, класс или функция должны иметь только одну причину для изменения. Это означает, что каждая сущность должна выполнять только одну четко определенную задачу или нести одну ответственность, которая полностью инкапсулирована внутри нее. Соблюдение этого принципа упрощает код, делает его более читаемым, легким для тестирования, поддержки и переиспользования"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#2-princip-edinstvennoj-otvetstvennosti"
  },
  {
    "label": "NEW_TAB_LINK",
    "_label": "SRP",
    "link": "https://pravosleva.pro/p/programming-solid-s",
    "target": "_blank"
  }
]'
/>

<CollapsibleBox
header="OCP: Open-Closed Principle"
text="### Принцип открытости-закрытости
Программные сущности должны быть открыты для расширения, но закрыты для изменений для снижения риска внесения ошибок при добавлении новой функциональности, улучшения расширяемости системы и упрощения поддержки существующего кода. Это достигается путем создания новых классов или модулей, которые дополняют существующие, вместо модификации уже написанного и проверенного кода"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#2-princip-otkrytostizakrytosti"
  },
  {
    "label": "NEW_TAB_LINK",
    "_label": "OCP",
    "link": "https://pravosleva.pro/p/programming-solid-o",
    "target": "_blank"
  }
]'
/>

<CollapsibleBox
header="LSP: Liskov Substitution Principle"
text="### Принцип подстановки Барбары Лисков
объекты подклассов должны быть заменяемы объектами их суперклассов без изменения корректности программы, то есть они должны дополнять, а не изменять поведение базового класса. Чтобы соответствовать LSP, дочерний класс не должен усиливать предусловия, ослаблять постусловия, нарушать инварианты (поведение) базового класса или генерировать непредусмотренные исключительные ситуации. Этот принцип является частью набора принципов проектирования SOLID в объектно-ориентированном программировании"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#2-princip-podstanovki-barbary-liskov"
  },
  {
    "label": "NEW_TAB_LINK",
    "_label": "LSP",
    "link": "https://pravosleva.pro/p/programming-solid-l",
    "target": "_blank"
  }
]'
/>

<CollapsibleBox
header="ISP: Interface Segregation Principle"
text="### Принцип разделения интерфейсов
Клиенты не должны зависеть от методов, которые они не используют. Вместо одного большого интерфейса рекомендуется создавать множество мелких, более специфичных интерфейсов. Это позволяет классам реализовывать только те методы, которые им действительно нужны, что снижает связанность кода, упрощает его тестирование и обслуживание, а также повышает общую качество системы"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#2-princip-razdeleniya-interfejsov"
  },
  {
    "label": "NEW_TAB_LINK",
    "_label": "ISP",
    "link": "https://pravosleva.pro/p/programming-solid-i",
    "target": "_blank"
  }
]'
/>

<CollapsibleBox
header="DIP: Dependency Inversion Principle"
text="### Принцип инверсии зависимостей
Высокоуровневые модули не должны зависеть от низкоуровневых, а оба типа модулей должны зависеть от абстракций (например, интерфейсов или абстрактных классов). Также абстракции не должны зависеть от деталей, а детали должны зависеть от абстракций. Этот принцип делает системы гибкими, модульными и легко расширяемыми, применяя его через методы, такие как внедрение зависимостей (Dependency Injection)"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#2-princip-inversii-zavisimostej"
  },
  {
    "label": "NEW_TAB_LINK",
    "_label": "DIP",
    "link": "https://pravosleva.pro/p/programming-solid-d",
    "target": "_blank"
  }
]'
/>

# Принципы SOLID

**Принципы SOLID** — это пять основных правил объектно-ориентированного проектирования классов. Они помогают создавать гибкий, понятный и легко поддерживаемый программный код. Автор концепции — американский инженер и программист **Роберт Мартин** (Дядюшка Боб).

Каждая буква в акрониме SOLID обозначает конкретный принцип:

* **S — Single Responsibility Principle (Принцип единственности ответственности)**
  Каждый класс должен решать только одну задачу. У него должна быть лишь одна причина для изменения кода.
  
* **O — Open-Closed Principle (Принцип открытости/закрытости)**
  Программные сущности открыты для расширения, но закрыты для модификации. Новые фичи добавляются через создание новых классов, а не через правку старого рабочего кода.
  
* **L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков)**
  Объекты в программе должны быть заменяемыми на экземпляры их подклассов без нарушения работы программы. Наследник должен дополнять, а не ломать поведение родителя.
  
* **I — Interface Segregation Principle (Принцип разделения интерфейса)**
  Клиенты не должны зависеть от методов, которые они не используют. Лучше создать много специализированных интерфейсов, чем один универсальный («толстый»).
  
* **D — Dependency Inversion Principle (Принцип инверсии зависимостей)**
  Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей, а детали — от абстракций.

### Главные преимущества SOLID:
* **Легкость поддержки**: код становится модульным.
* **Удобство тестирования**: проще писать Unit-тесты.
* **Гибкость**: легко добавлять новые фичи.
* **Читаемость**: разработчикам проще разбираться в структуре.

## Принцип единственной ответственности
> Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.

**Инкапсуляция** в программировании — это принцип, согласно которому внутреннее устройство сущностей нужно объединять в специальной «оболочке» и скрывать от вмешательств извне. Доступ к объектам возможен через специальные открытые методы, а напрямую обратиться к их содержимому нельзя.

Инкапсуляцию также описывают как принцип разделения логики и поведения. Логика — то, как что-то устроено внутри. Поведение — то, как оно взаимодействует с другими сущностями. Разделение этих двух понятий упрощает взаимодействие объектов в коде.

```js
class News {
    constructor(title, text) {
        this.title = title
        this.text = text
        this.modified = false
    }

    update(text) {
        this.text = text
        this.modified = true
    }
}

class NewsPrinter {
    constructor(news) {
        this.news = news
    }

    html() {
        return `
            <div class="news">
                <h1>${this.news.title}</h1>
                <p>${this.news.text}</p>
            </div>
        `
    }

    json() {
        return JSON.stringify({
            title: this.news.title,
            text: this.news.text,
            modified: this.news.modified
        })
    }
}

const printer = new NewsPrinter(
    new News('News title', 'News text')
)

console.log(printer.html())
/*
    <div class="news">
        <h1>News title</h1>
        <p>News text</p>
    </div>
*/

console.log(printer.json())
/*
    {"title":"News title","text":"News text","modified":false}
*/
```

## Принцип открытости/закрытости
> Программные сущности (классы, модули, функции) должны быть открыты для расширения, но не для модификации.

```js
class Shape {
    area() {
        throw new Error('Area method should be implemented!')
    }
}

class Square extends Shape {
    constructor(size) {
        super()
        this.size = size
    }

    area() {
        return this.size ** 2
    }
}

class Circle extends Shape {
    constructor(radius) {
        super()
        this.radius = radius
    }

    area() {
        return (this.radius ** 2) * Math.PI
    }
}

class AreaCalculator {
    constructor(shapes = []) {
        this.shapes = shapes
    }

    sum() {
        return this.shapes.reduce((acc, shape) => {
            acc += shape.area()

            return acc
        }, 0)
    }
}

const calc = new AreaCalculator([
    new Square(2),
    new Circle(5)
])

console.log(calc.sum())  // 82.53981633974483
```

## Принцип подстановки Барбары Лисков
> Если у нас есть программа, использующая объект базового класса, то при замене этого объекта на объект его подкласса программа должна работать точно так же, без каких-либо изменений. 

```js
class Person {}

class Member extends Person {
    access() {
        console.log('You have an access.')
    }
}

class Guest extends Person {
    isGuest = true
}

class Frontend extends Member {
    canCreateFrontend() {}
}

class Backend extends Member {
    canCreateBackend() {}
}

class PersonFromDifferentCompany extends Guest {
    access() {
        throw new Error('You haven\'t access!')
    }
}

function openSecretDoor(member) {
    member.access()
}

openSecretDoor(new Frontend())  // You have an access.
openSecretDoor(new Backend())  // You have an access.
openSecretDoor(new PersonFromDifferentCompany())  // Uncaught Error: You haven't access!
```

## Принцип разделения интерфейсов
> 1. Избегание "жирных" интерфейсов: Вместо одного интерфейса с большим количеством методов, который вынуждает классы реализовывать все подряд, создаются более мелкие, специализированные интерфейсы.
>
> 2. Снижение зависимостей: Каждый класс зависит только от тех методов, которые ему нужны для работы, что уменьшает влияние изменений в других частях системы.
>
> 3. Повышение гибкости: Изменения в одном мелком интерфейсе не затронут классы, которые его не используют, делая систему более гибкой и легко поддерживаемой. 

```js
class Animal {
    constructor(name) {
        this.name = name
    }
}

const walker = {
    walk() {
        console.log(`${this.name} can walk.`)
    }
}

const swimmer = {
    swim() {
        console.log(`${this.name} can swim.`)
    }
}

const flier = {
    fly() {
        console.log(`${this.name} can fly.`)
    }
}

class Dog extends Animal {}
class Eagle extends Animal {}
class Whale extends Animal {}

Object.assign(Dog.prototype, walker, swimmer)
Object.assign(Eagle.prototype, walker, flier)
Object.assign(Whale.prototype, swimmer)

const dog = new Dog('Leo')

dog.walk()  // Leo can walk.
dog.swim()  // Leo can swim.

const eagle = new Eagle('Vu')

eagle.walk()  // Vu can walk.
eagle.fly()  // Vu can fly.

const whale = new Whale('Bubba')

whale.swim()  // Bubba can swim.
```

## Принцип инверсии зависимостей
> Система должна конструироваться на основе абстракций “сверху вниз”: не абстракции должны формироваться на основе деталей, а детали должны формироваться на основе абстракций

```js
class Fetch {
    request(url) {
        // return fetch(url).then(response => response.json())
        return Promise.resolve('Data from fetch.')
    }
}

class LocalStorage {
    get() {
        const dataFromLocalStorage = 'Data from LocalStorage.'
        return dataFromLocalStorage
    }
}

class FetchClient {
    constructor() {
        this.fetch = new Fetch()
    }

    clientGet() {
        return this.fetch.request()
    }
}

class LocalStorageClient {
    constructor() {
        this.localStorage = new LocalStorage()
    }

    clientGet() {
        return this.localStorage.get()
    }
}

class Database {
    constructor(client) {
        this.client = client
    }

    getData() {
        return this.client.clientGet()
    }
}

const db = new Database(new FetchClient())

console.log(db.getData())  // Promise {<fulfilled>: "Data from fetch."}

const localStorage = new Database(new LocalStorageClient())

console.log(localStorage.getData())  // Data from LocalStorage.
```

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "Принципы ООП",
      "type": "link",
      "link": "/blog/article/programming-oop"
    },
    {
      "title": "NEXT",
      "label": "Перестаньте молиться на принципы SOLID (habr 2025.01)",
      "type": "link",
      "link": "https://habr.com/ru/articles/874584/"
    }
  ]'
/>

Принципы SOLID

*See also: [DI samples by Andrey Melichov](https://github.com/amel-true/lessons/tree/master/di)*

#solid #DependencyInjection #Мелихов #DI

## DI example в функциональном реакт

Многошаговая форма Stepper получает массив шагов + некие пропсы `TStep`, пробрасываемые в каждый шаг. Stepper настолько глуп, что ничего не знает из чего состоит стандарт `TStep`, и чем занимаются его дети.

*Пример:*
```tsx
type TStepContentProps = {
  prop1: number
}

const steps = [
  {
    title: 'Do something',
    content: ({ prop1 }: TStepContentProps) => {
      return (
        <em>I know about <code>{JSON.stringify(prop1, null, 2)}</code></em>
      )
    },
  },
]

const App = () => {
  <div>
    <h2>Stupid Stepper example</h2>
    <Stepper
      steps={steps}
      // Другие пропсы, про которые знает Stepper: nClose, onSave, onCancel
      // REST props, про которые знает только рендерируемый Step: data, formData, onInputChange, normalizedForm, formErrors
    />
  </div>
}
```

### *Stepper like Material*
```tsx
type TProps = {
  onSave: () => void
  steps: {
    title: string
    description?: string
    content: React.FC<any> // LOOK: Stepper не знает, чем занимаются его дети =)
  }[]
  onClose?: () => void
  onCancel: () => void

  // REST:
  [key: string]: any
  // data: any
  // formData: any
  // onInputChange: any
  // getNormalizedForm: (form: any) => any
  formErrors: {
    [key: string]: any
    blockedSteps?: number[]
  }
}

export const Stepper = ({ onClose, onSave, onCancel, steps, ...rest }: TProps) => {
  const classes = useStyles()
  const [activeStep, setActiveStep] = React.useState(0)
  const handleNext = () => { setActiveStep((prevActiveStep) => prevActiveStep + 1) }
  const handleBack = () => { setActiveStep((prevActiveStep) => prevActiveStep - 1) }
  const handleResetStep = () => { setActiveStep(0) }
  const finalHandler = () => {
    onSave()
    if (!!onClose) onClose()
  }
  const handleCancel = useCallback(() => {
    onCancel()
    handleResetStep()
  }, [onCancel, handleResetStep])

  return (
    <div className={classes.root}>
      <MuiStepper
        activeStep={activeStep}
        orientation="vertical"
        className={classes.stepper}
      >
        {steps.map(({ title, description, content }, index) => (
          <Step key={index}>
            <StepLabel>{title}</StepLabel>
            <StepContent>
              {!!description && <div className={classes.descriptionContent}>{description}</div>}
              <div className={classes.jsxContent}>{content({ ...rest })}</div>
              <div className={classes.actionsContainer}>
                <div>
                  <Button size="small" disabled={activeStep === 0} onClick={handleBack} className={classes.button}>
                    Back
                  </Button>
                  <Button
                    size="small"
                    variant="contained"
                    color="primary"
                    onClick={handleNext}
                    className={classes.button}
                    disabled={rest.formErrors?.blockedSteps?.includes(activeStep)}
                  >
                    {activeStep === steps.length - 1 ? 'Finish' : 'Next'}
                  </Button>
                </div>
              </div>
            </StepContent>
          </Step>
        ))}
      </MuiStepper>
      {activeStep === steps.length && (
        <Paper square elevation={0} className={classes.resetContainer}>
          <div>All steps completed - you&apos;re finished</div>
          <Button
            color="secondary"
            size="small"
            variant="outlined"
            onClick={handleResetStep}
            className={classes.button}
          >
            Go Start
          </Button>
          <Button color="secondary" size="small" variant="contained" onClick={handleCancel} className={classes.button}>
            Cancel
          </Button>
          <Button color="primary" size="small" variant="contained" onClick={finalHandler} className={classes.button}>
            Save
          </Button>
        </Paper>
      )}
      {!!onClose && activeStep !== steps.length && (
        <Button color="secondary" size="small" variant="outlined" onClick={onClose} className={classes.button}>
          Close
        </Button>
      )}
    </div>
  )
}
```

*[Example in project](https://github.com/pravosleva/next-mongodb/blob/master/common/components/PinnedNotesNamespaceMap/components/LSControl/components/EditBtn/EditBtn.tsx)*

solid