Как ссылка на instance класса попадает из наружного слоя в бизнес-логику?

Архитектурный подход и внедрение зависимостей

В современной frontend-разработке, особенно с использованием React, Vue или Angular, передача экземпляра класса из внешнего слоя (например, UI или инфраструктуры) в слой бизнес-логики обычно реализуется через паттерны управления зависимостями и принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Основные механизмы передачи

1. Внедрение через конструктор (Constructor Injection)

Наиболее распространённый способ. Экземпляр класса внешнего слоя передаётся в бизнес-логику при её инициализации.

// Внешний слой (инфраструктура)
class ExternalService {
  fetchData() {
    return api.get('/data');
  }
}

// Бизнес-логика
class BusinessLogic {
  private externalService: ExternalService;

  constructor(externalService: ExternalService) {
    this.externalService = externalService;
  }

  async processData() {
    const data = await this.externalService.fetchData();
    // Обработка данных
  }
}

// Композиция на верхнем уровне
const externalService = new ExternalService();
const businessLogic = new BusinessLogic(externalService);

2. Внедрение через сеттер (Setter Injection)

Полезно, когда зависимость может меняться в течение жизненного цикла объекта.

class BusinessLogic {
  setExternalService(service) {
    this.externalService = service;
  }
}

3. Использование контейнера зависимостей (DI Container)

Библиотеки вроде InversifyJS или встроенные механизмы Angular автоматически управляют зависимостями.

import { injectable, inject, Container } from 'inversify';

@injectable()
class ExternalService {}

@injectable()
class BusinessLogic {
  constructor(@inject(ExternalService) private externalService) {}
}

const container = new Container();
container.bind(ExternalService).toSelf();
container.bind(BusinessLogic).toSelf();

const businessLogic = container.get(BusinessLogic);

Практические примеры в React-экосистеме

Контекст и хуки

// Создаём контекст для сервиса
const ExternalServiceContext = React.createContext();

// Внешний слой (провайдер)
function App() {
  const externalService = new ExternalService();
  
  return (
    <ExternalServiceContext.Provider value={externalService}>
      <BusinessComponent />
    </ExternalServiceContext.Provider>
  );
}

// Бизнес-компонент
function BusinessComponent() {
  const externalService = useContext(ExternalServiceContext);
  
  const handleBusinessLogic = async () => {
    // Использование переданного экземпляра
    const data = await externalService.fetchData();
    // Бизнес-логика обработки
  };
  
  return <button onClick={handleBusinessLogic}>Выполнить</button>;
}

Кастомные хуки для инкапсуляции логики

function useBusinessLogic(externalService) {
  const processData = async () => {
    // Бизнес-логика, использующая внешний сервис
    const data = await externalService.fetchData();
    return transformData(data);
  };
  
  return { processData };
}

// Использование в компоненте
function Component() {
  const externalService = useExternalService();
  const { processData } = useBusinessLogic(externalService);
}

Ключевые принципы и преимущества

Принцип инверсии зависимостей

• Бизнес-логика не создаёт зависимости сама, а получает их извне
• Снижение связанности между слоями приложения
• Упрощение тестирования через моки и стабы

// Тестирование с моком
test('BusinessLogic process data', () => {
  const mockService = {
    fetchData: jest.fn().mockResolvedValue({ id: 1 })
  };
  
  const businessLogic = new BusinessLogic(mockService);
  // Тестирование без реальных внешних вызовов
});

Архитектурные паттерны

• Clean Architecture / Onion Architecture: внешние слои зависят от внутренних, но не наоборот
• Domain-Driven Design: чёткое разделение доменной логики и инфраструктуры
• Hexagonal Architecture: порты и адаптеры для изоляции бизнес-логики

Распространённые антипаттерны

1. Прямое создание зависимостей в бизнес-логике

   // ПЛОХО: сильная связанность
   class BusinessLogic {
     constructor() {
       this.externalService = new ExternalService(); // Прямое создание
     }
   }
   

2. Глобальные экземпляры (синглтоны)

   // ПЛОХО: сложно тестировать, скрытые зависимости
   class BusinessLogic {
     constructor() {
       this.externalService = ExternalService.getInstance();
     }
   }
   

Практические рекомендации

1. Определите чёткие интерфейсы для взаимодействия между слоями
2. Используйте TypeScript/Flow для контроля типов зависимостей
3. Внедряйте зависимости на верхнем уровне приложения (композиция корня)
4. Рассмотрите использование DI-контейнера для сложных приложений
5. Разделяйте создание и использование объектов (принцип разделения ответственности)

Такой подход обеспечивает гибкость, тестируемость и поддерживаемость кода, позволяя легко заменять реализации внешних сервисов без изменения бизнес-логики.