Как избавиться от Coupling в парадигме ООП?

Как избавиться от Coupling в парадигме ООП

Что такое Coupling

Coupling (связанность) — это степень, в которой классы, модули или компоненты зависят друг от друга. Высокая связанность (tight coupling) — это плохо, низкая связанность (loose coupling) — это хорошо.

Проблемы high coupling:

// Плохо: UserController сильно зависит от UserService и Database
class UserController {
  constructor() {
    this.userService = new UserService(); // Hard dependency
    this.database = new Database();        // Hard dependency
  }

  getUser(id) {
    const user = this.database.query(`SELECT * FROM users WHERE id = ${id}`);
    return this.userService.formatUser(user);
  }
}

Проблемы:

• Сложно тестировать (нельзя подменить UserService)
• Сложно менять реализацию (нужно менять код класса)
• Сложно переиспользовать (везёт с собой зависимости)

Решение 1: Dependency Injection (DI)

Инъекция зависимостей — самый важный инструмент для снижения coupling.

// Хорошо: Зависимости передаются в конструктор
class UserController {
  constructor(userService, database) {
    this.userService = userService; // Зависимость инъецируется
    this.database = database;       // Зависимость инъецируется
  }

  getUser(id) {
    const user = this.database.query(`SELECT * FROM users WHERE id = ${id}`);
    return this.userService.formatUser(user);
  }
}

// Использование
const userService = new UserService();
const database = new Database();
const controller = new UserController(userService, database);

// Тестирование — легко подменить
const mockService = { formatUser: () => ({ id: 1, name: "Test" }) };
const mockDb = { query: () => ({ id: 1 }) };
const testController = new UserController(mockService, mockDb);

Решение 2: Абстрактные классы и интерфейсы

Зависеть от абстракций, а не от конкретных реализаций (SOLID: Dependency Inversion Principle).

// Абстрактный интерфейс (контракт)
class DatabaseInterface {
  query(sql) {
    throw new Error("Not implemented");
  }
}

// Конкретная реализация
class PostgresDatabase extends DatabaseInterface {
  query(sql) {
    // Подключение к Postgres
    return [...результаты...];
  }
}

class MongoDatabase extends DatabaseInterface {
  query(sql) {
    // Подключение к MongoDB
    return [...результаты...];
  }
}

// UserController зависит от интерфейса, а не от конкретной БД
class UserController {
  constructor(userService, database) {
    this.database = database; // DatabaseInterface
  }

  getUser(id) {
    // Этот код работает с ЛЮБОЙ реализацией DatabaseInterface
    return this.database.query(`SELECT * FROM users WHERE id = ${id}`);
  }
}

// Легко переключаться между реализациями
const pgDb = new PostgresDatabase();
const controller = new UserController(userService, pgDb);

// Или
const mongoDb = new MongoDatabase();
const controller = new UserController(userService, mongoDb);

Решение 3: Service Locator / IoC Container

IoC (Inversion of Control) контейнер — централизованное управление зависимостями.

// Container управляет всеми зависимостями
class Container {
  constructor() {
    this.services = {};
  }

  register(name, factory) {
    this.services[name] = factory;
  }

  get(name) {
    const factory = this.services[name];
    if (!factory) throw new Error(`Service ${name} not found`);
    return factory();
  }
}

// Настройка контейнера
const container = new Container();

container.register("database", () => new PostgresDatabase());
container.register("userService", () => new UserService());
container.register("userController", () => 
  new UserController(
    container.get("userService"),
    container.get("database")
  )
);

// Использование
const controller = container.get("userController");

// Для тестирования просто переконфигурируем контейнер
container.register("database", () => new MockDatabase());
const testController = container.get("userController");

Решение 4: Composition над наследованием

High coupling часто возникает из глубокой иерархии наследования.

// Плохо: Глубокая иерархия
class Vehicle {}
class Car extends Vehicle {}
class SportsCar extends Car {}
class RedSportsCar extends SportsCar {} // coupling nightmare

// Хорошо: Composition
class Car {
  constructor(engine, wheels, color) {
    this.engine = engine;
    this.wheels = wheels;
    this.color = color;
  }

  drive() {
    this.engine.start();
    this.wheels.rotate();
  }
}

const sportsCar = new Car(
  new V8Engine(),
  new RacingWheels(),
  new Color("red")
);

Решение 5: Events / Observer Pattern

Компоненты общаются через события, а не через прямые вызовы.

// Плохо: UserController знает о UserService напрямую
class UserController {
  deleteUser(id) {
    const user = this.userService.delete(id);
    // Нужно вызвать все компоненты, которые должны знать об удалении
    this.emailService.sendDeletionEmail(user);
    this.analyticsService.logDeletion(user);
    this.cacheService.invalidate(id);
  }
}

// Хорошо: UserController публикует событие
class EventBus {
  constructor() {
    this.listeners = {};
  }

  on(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
  }

  emit(event, data) {
    if (this.listeners[event]) {
      this.listeners[event].forEach(callback => callback(data));
    }
  }
}

class UserController {
  constructor(eventBus) {
    this.eventBus = eventBus;
  }

  deleteUser(id) {
    // Удаляем пользователя
    const user = { id };
    
    // Публикуем событие — кто слушает, сам разберётся
    this.eventBus.emit("user:deleted", user);
  }
}

// Другие компоненты слушают событие
const eventBus = new EventBus();

const emailService = new EmailService();
emailBus.on("user:deleted", (user) => {
  emailService.sendDeletionEmail(user);
});

const analyticsService = new AnalyticsService();
eventBus.on("user:deleted", (user) => {
  analyticsService.logDeletion(user);
});

const controller = new UserController(eventBus);

Решение 6: Правило Dependency Inversion (SOLID)

D in SOLID — зависи от абстракций, а не от конкреций.

// Плохо
class PaymentProcessor {
  constructor() {
    this.creditCardProcessor = new CreditCardProcessor();
    this.paypalProcessor = new PayPalProcessor();
  }

  process(payment) {
    if (payment.method === "credit_card") {
      return this.creditCardProcessor.process(payment);
    } else if (payment.method === "paypal") {
      return this.paypalProcessor.process(payment);
    }
  }
}

// Хорошо: Зависимости от интерфейса
class PaymentProcessor {
  constructor(paymentMethod) {
    this.paymentMethod = paymentMethod; // PaymentMethodInterface
  }

  process(payment) {
    return this.paymentMethod.process(payment);
  }
}

interface PaymentMethod {
  process(payment): Promise<Result>;
}

class CreditCardProcessor implements PaymentMethod {
  process(payment) { ... }
}

class PayPalProcessor implements PaymentMethod {
  process(payment) { ... }
}

// Использование
const processor = new PaymentProcessor(new CreditCardProcessor());

Практический пример: React компоненты

// Плохо: Компонент создает зависимости
function UserProfile() {
  const api = new UserAPI(); // Hard dependency
  const [user, setUser] = useState(null);

  useEffect(() => {
    api.getUser().then(setUser);
  }, []);

  return <div>{user?.name}</div>;
}

// Хорошо: Зависимости передаются через props/context
function UserProfile({ userService }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    userService.getUser().then(setUser);
  }, [userService]);

  return <div>{user?.name}</div>;
}

// Использование
<UserProfile userService={new UserService()} />

// Тестирование
<UserProfile userService={mockUserService} />

Чеклист снижения Coupling

• Используй Dependency Injection
• Зависи от интерфейсов, а не от конкреций
• Избегай глубокого наследования (используй composition)
• Используй Event Bus вместо прямых вызовов
• Избегай hard-coded зависимостей в конструкторах
• Применяй SOLID принципы (особенно DIP)
• Тестируй с mock-объектами

Вывод

Coupling снижается через:

1. Dependency Injection — передавай зависимости, не создавай их
2. Абстракции (интерфейсы) — зависи от контрактов, не от реализаций
3. Events — общайся через события, не через прямые вызовы
4. Composition — составляй из независимых частей
5. SOLID принципы — особенно Dependency Inversion

Цель: каждый класс должен отвечать за одно и зависеть только от необходимого минимума.