Что такое проблема high coupling и low coupling в монолите?

Что такое проблема high coupling и low coupling в монолите?

Связанность (coupling) в программировании — это степень зависимости между компонентами кода. High coupling (высокая связанность) означает, что компоненты сильно зависят друг от друга, а low coupling (низкая связанность) — когда компоненты независимы и слабо связаны.

В монолитной архитектуре проблема coupling особенно критична, так как все компоненты находятся в одном приложении и влияют друг на друга.

High Coupling — проблема

High coupling приводит к тесным связям между модулями, что делает код хрупким и сложным в поддержке:

# ПЛОХО: High Coupling
class UserService:
    def __init__(self):
        self.email_service = EmailService()      # Прямая зависимость
        self.payment_service = PaymentService()  # Прямая зависимость
        self.database = Database()               # Прямая зависимость
    
    def register_user(self, email: str, password: str):
        # Сервис знает о деталях реализации других компонентов
        user = self.database.insert_user(email, password)
        self.email_service.send_confirmation(email)  # Жёсткая зависимость
        self.payment_service.create_account(user.id) # Жёсткая зависимость
        return user

Проблемы:

• Невозможно тестировать UserService без инстанцирования всех зависимостей
• Изменение EmailService требует изменения UserService
• Сложно переиспользовать компоненты
• Каждое изменение может сломать другие части

Low Coupling — решение

Low coupling достигается через инверсию зависимостей (Dependency Inversion):

# ХОРОШО: Low Coupling (Dependency Injection)
from abc import ABC, abstractmethod
from typing import Protocol

# Определяем интерфейсы
class EmailSender(Protocol):
    def send(self, email: str, subject: str, body: str) -> bool:
        ...

class PaymentProcessor(Protocol):
    def create_account(self, user_id: int) -> bool:
        ...

class UserRepository(Protocol):
    def save(self, email: str, password: str) -> dict:
        ...

# Сервис зависит от интерфейсов, а не от реализаций
class UserService:
    def __init__(
        self,
        email_sender: EmailSender,
        payment_processor: PaymentProcessor,
        user_repo: UserRepository
    ):
        # Инъекция зависимостей — сервис не создаёт объекты
        self.email_sender = email_sender
        self.payment_processor = payment_processor
        self.user_repo = user_repo
    
    def register_user(self, email: str, password: str) -> dict:
        # Работает с интерфейсами, не с конкретными реализациями
        user = self.user_repo.save(email, password)
        self.email_sender.send(
            email,
            "Welcome!",
            "Confirm your email"
        )
        self.payment_processor.create_account(user['id'])
        return user

# Реальные реализации
class SmtpEmailSender:
    def send(self, email: str, subject: str, body: str) -> bool:
        # Отправляет через SMTP
        return True

class StripePaymentProcessor:
    def create_account(self, user_id: int) -> bool:
        # Создаёт аккаунт в Stripe
        return True

class PostgresUserRepository:
    def save(self, email: str, password: str) -> dict:
        # Сохраняет в PostgreSQL
        return {"id": 1, "email": email}

# Composing в точке входа (IoC контейнер)
class ApplicationFactory:
    @staticmethod
    def create_user_service() -> UserService:
        return UserService(
            email_sender=SmtpEmailSender(),
            payment_processor=StripePaymentProcessor(),
            user_repo=PostgresUserRepository()
        )

# Использование
service = ApplicationFactory.create_user_service()
user = service.register_user("john@example.com", "secure_pass")

Тестирование при Low Coupling

С низкой связанностью тестирование становится тривиальным:

# Тестирование с mock'ами
class MockEmailSender:
    def send(self, email: str, subject: str, body: str) -> bool:
        return True

class MockPaymentProcessor:
    def create_account(self, user_id: int) -> bool:
        return True

class MockUserRepository:
    def save(self, email: str, password: str) -> dict:
        return {"id": 1, "email": email}

def test_register_user():
    # Создаём сервис с mock'ами
    service = UserService(
        email_sender=MockEmailSender(),
        payment_processor=MockPaymentProcessor(),
        user_repo=MockUserRepository()
    )
    
    # Тестируем в изоляции
    result = service.register_user("test@example.com", "pass")
    assert result["email"] == "test@example.com"

Проблемы High Coupling в монолите

1. Изменения распространяются по цепочке

# ПЛОХО
class PaymentService:
    def __init__(self):
        self.email = EmailService()  # Прямая зависимость

# Изменение EmailService влияет на PaymentService

2. Сложность тестирования

# Для тестирования PaymentService нужно:
# - Инстанцировать EmailService
# - Инстанцировать Database (в EmailService)
# - Инстанцировать ExternalEmailProvider (в EmailService)
# - И всё это для проверки одного платежа!

3. Невозможно переиспользовать

# Хочу использовать PaymentService в другом проекте
# Но он привязан к конкретной реализации EmailService
# Приходится копировать весь код

Как снизить Coupling

1. Dependency Injection (DI)

class Service:
    def __init__(self, repository: RepositoryInterface):
        self.repo = repository  # Инъекция, не создание

2. Interfaces/Protocols

from typing import Protocol

class Logger(Protocol):
    def log(self, message: str) -> None: ...

# Любой объект с методом log() подходит

3. Избегать глобального состояния

# ПЛОХО: глобальное состояние
db = Database()  # Глобальный объект

class UserService:
    def get_user(self, id: int):
        return db.query(...)  # Зависит от глобального db

# ХОРОШО: инъекция
class UserService:
    def __init__(self, db: DatabaseConnection):
        self.db = db

4. Event-driven архитектура

# Модули общаются через события, не напрямую
class UserRegisteredEvent:
    def __init__(self, user_id: int, email: str):
        self.user_id = user_id
        self.email = email

class UserService:
    def __init__(self, event_bus: EventBus):
        self.event_bus = event_bus
    
    def register_user(self, email: str):
        user = self._create_user(email)
        # Другие сервисы подписаны на это событие
        self.event_bus.publish(UserRegisteredEvent(user.id, email))
        return user

# EmailService подписан на событие
class EmailService:
    def on_user_registered(self, event: UserRegisteredEvent):
        self.send_confirmation_email(event.email)

Сравнение

В контексте монолита

В монолитной архитектуре low coupling критичен, потому что:

• Все части работают в одном процессе
• Изменение одного компонента может сломать весь монолит
• Сложнее масштабировать (невозможно выделить часть в микросервис, если она спутана с другими)

Вывод: Low coupling достигается через инверсию зависимостей, использование интерфейсов и dependency injection. Это делает код более тестируемым, поддерживаемым и готовым к будущим изменениям — критично для долгоживущего монолита.