Что такое зацепление кода?

Что такое зацепление кода?

Зацепление кода (Code Coupling) — это степень взаимной зависимости между отдельными модулями, компонентами или классами в программе. Это мера того, насколько один модуль зависит от деталей реализации другого.

Основные понятия

Определение: Зацепление описывает, как тесно связаны различные части системы. Высокое зацепление означает, что модули сильно зависят друг от друга, а низкое — что они независимы и слабо взаимодействуют.

Типы зацепления

1. Плотное зацепление (Tight Coupling) — плохо:

class Order {
public:
    void process() {
        PaymentProcessor processor;
        processor.charge(100.0);
    }
};

Здесь Order напрямую создаёт PaymentProcessor, что делает их тесно связанными. Изменение PaymentProcessor повлияет на Order.

2. Слабое зацепление (Loose Coupling) — хорошо:

class IPaymentProcessor {
public:
    virtual ~IPaymentProcessor() = default;
    virtual void charge(double amount) = 0;
};

class Order {
private:
    IPaymentProcessor* processor;
public:
    Order(IPaymentProcessor* p) : processor(p) {}
    
    void process() {
        processor->charge(100.0);
    }
};

Здесь Order зависит от интерфейса, а не от конкретной реализации. Легко подставить другой процессор платежей.

Уровни зацепления

Внутренний уровень (Data Coupling): Модули обмениваются только элементарными данными (скаляры, примитивные типы).

void calculateTax(double income) {
    // Минимальное зацепление
}

Параметрическое зацепление (Stamp Coupling): Модули обмениваются структурами или объектами, но используют не все поля.

struct Person {
    std::string name;
    int age;
    std::string address;
};

void printName(const Person& p) {
    // Использует только name, но получает весь объект
}

Управляющее зацепление (Control Coupling): Один модуль передаёт флаги, управляющие поведением другого.

void processData(std::vector<int>& data, bool sort) {
    if (sort) {
        std::sort(data.begin(), data.end());
    }
    // Высокое управляющее зацепление
}

Общее зацепление (Common Coupling): Несколько модулей работают с одной глобальной переменной.

global_config g_config;  // Глобальная переменная

void moduleA() {
    g_config.value = 10;
}

void moduleB() {
    std::cout << g_config.value;  // Высокое зацепление через глобал
}

Содержательное зацепление (Content Coupling): Один модуль обращается к внутренним деталям другого (очень плохо).

class DatabaseConnection {
pubate:
    int* internal_buffer;  // Внутренняя деталь
};

void someFunction(DatabaseConnection& db) {
    db.internal_buffer[0] = 5;  // Прямой доступ к внутренностям
}

Практические примеры в Backend

Плохо — тесная связь:

class UserRepository {
public:
    void saveUser(User u) {
        // Прямая работа с файловой системой
        std::ofstream file("users.txt", std::ios::app);
        file << u.id << "," << u.name << "\n";
    }
};

class UserService {
private:
    UserRepository repo;  // Жёсткая зависимость
public:
    void registerUser(User u) {
        repo.saveUser(u);
    }
};

Хорошо — слабая связь:

interface IUserRepository {
    virtual void save(const User& u) = 0;
};

class FileUserRepository : public IUserRepository {
public:
    void save(const User& u) override {
        // Реализация для файлов
    }
};

class DatabaseUserRepository : public IUserRepository {
public:
    void save(const User& u) override {
        // Реализация для БД
    }
};

class UserService {
private:
    std::unique_ptr<IUserRepository> repo;
public:
    UserService(std::unique_ptr<IUserRepository> r) : repo(std::move(r)) {}
    
    void registerUser(const User& u) {
        repo->save(u);
    }
};

Как снизить зацепление

1. Используй интерфейсы (Dependency Inversion): Зависи от абстракций, а не от конкретных реализаций.

2. Инъекция зависимостей (Dependency Injection): Передавай зависимости через конструктор вместо создания их внутри.

3. Избегай глобальных переменных: Они — главный враг слабого зацепления.

4. Инкапсуляция: Предоставляй только публичный интерфейс, скрывай внутренние детали.

5. Разделение ответственности: Один класс — одна причина для изменения (Single Responsibility).

Преимущества низкого зацепления

• Тестируемость: Легче писать unit-тесты с mock-объектами
• Переиспользуемость: Модули можно использовать в разных проектах
• Поддерживаемость: Изменения в одном модуле не ломают другие
• Масштабируемость: Легче добавлять новые функции
• Гибкость: Легче менять реализацию без изменения интерфейса