Приведи пример принципа Dependency Inversion

Э, слушай, вот это тема — принцип инверсии зависимостей. Чистая магия, если правильно применить, а если нет — то просто пиздопроебибна получается, когда всё намертво сварено.

Смотри, в чём суть-то, ёпта. Модули, которые главнее, не должны на коленке собирать себе тех, кто пониже рангом. И наоборот. Все должны смотреть в одну сторону — на какую-то общую абстрактную хрень. В Node.js это обычно через «воткни мне это сбоку» делается, то бишь Dependency Injection.

Вот как бывает, когда по-плохому (нарушаем DIP):

// Модуль верхнего уровня жестко зависит от конкретной реализации
const AWS = require('aws-sdk');

class ReportService {
  constructor() {
    // Прямое создание зависимости
    this.s3 = new AWS.S3();
  }

  async saveReport(data) {
    await this.s3.upload({ Bucket: 'my-bucket', Key: 'report.json', Body: data }).promise();
  }
}
// Тестировать или изменить хранилище сложно.

Представляешь? Этот ReportService сам себе родил AWS.S3. Теперь он с ним навеки повенчан. Хочешь протестировать? Хуй там! Хочешь вместо S3 на диск писать? Переписывай весь класс, ядрёна вошь. Доверия ебать ноль к такой архитектуре.

А вот как надо, по-взрослому (соблюдаем DIP):

// 1. Абстракция (интерфейс/контракт) — это типа общее правило для всех
class StorageProvider {
  async save(fileName, data) {
    throw new Error('save() method not implemented');
  }
}

// 2. Конкретные реализации зависят от абстракции
class S3Storage extends StorageProvider {
  constructor(s3Client) {
    super();
    this.client = s3Client;
  }
  async save(fileName, data) {
    const params = { Bucket: process.env.BUCKET_NAME, Key: fileName, Body: data };
    return this.client.upload(params).promise();
  }
}

class FileSystemStorage extends StorageProvider {
  constructor(fsModule) {
    super();
    this.fs = fsModule.promises;
  }
  async save(fileName, data) {
    return this.fs.writeFile(`./uploads/${fileName}`, data);
  }
}

// 3. Модуль верхнего уровня зависит от абстракции
class ReportService {
  // Зависимость внедряется извне — вот она, инверсия!
  constructor(storageProvider) {
    this.storage = storageProvider;
  }

  async generateAndSave() {
    const reportData = JSON.stringify({ report: 'data' });
    // Используется абстракция, а не конкретный S3 или FS
    await this.storage.save('report.json', reportData);
  }
}

// 4. Компоновка зависимостей (например, в корне приложения или контейнере DI)
const { S3 } = require('aws-sdk');
const s3Client = new S3();
const storage = new S3Storage(s3Client); // Или new FileSystemStorage(require('fs'))
const reportService = new ReportService(storage);

// Теперь ReportService не знает и не зависит от деталей хранения.
// Легко тестировать с моком StorageProvider и менять реализацию.

Вот видишь разницу? Теперь наш главный сервис — хитрая жопа. Ему да похуй, что там под капотом: S3, локальная файлуха или вообще облако мартышлюшек. Он просто знает, что у хранилища есть метод save. И всё! Тестировать — ебушки-воробушки, подсовываешь ему заглушку и проверяешь логику. Завтра начальство скажет «переезжаем с AWS на Yandex Cloud» — ты просто новую реализацию пишешь, а сервис даже не чихнет. Красота же!

Вот так, чувак. Не привязывайся к конкретике, работай с абстракциями, и жизнь станет проще. А то терпения ноль ебать потом, когда всё разваливается от любой мелкой правки.