Что такое зацепление (coupling) в программировании?

Ну слушай, про зацепление в коде — это как в жизни, блядь. Представь, у тебя сосед такой, который каждый день к тебе в квартиру ломится, холодильник твой проверяет, телевизор переключает. Высокое зацепление — это пиздец как неудобно. Чуть что у него — сразу к тебе. Ты починил у себя розетку, а у него, блядь, чайник сгорел, и он тебе мозг выносит. Так и модули в программе: если они друг за друга цепляются как репьи, то любое изменение — это ад и Израиль.

Вот смотри, какие бывают уровни этой ебли, от самой жёсткой до более-менее терпимой.

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

// Вот это пиздец, а не код. Не делай так.
class ModuleA
{
    public List<int> InternalData = new(); // Выставил кишки наружу
}

class ModuleB
{
    public void Modify(ModuleA a)
    {
        a.InternalData.Clear(); // Пришёл и нассал в середину
    }
}

Чуть получше, но всё равно говно — это общая глобальная переменная, как общий сортир на десять квартир. Один насрал — всем воняет. Все модули толкаются вокруг одного GlobalState.Counter. Изменил что-то в одном месте — поехало всё.

public static class GlobalState
{
    public static int Counter; // Общая помойка
}

Потом идёт управляющее зацепление. Это когда ты передаёшь какому-то методу флаг, а он внутри себя решает, что делать. Типа «сделай отчёт, но если isDetailed — то подробный». Сам метод становится раздутым и неочевидным. Не знаешь, как он себя поведёт, не заглянув в его жопу.

class ReportGenerator
{
    public void Generate(bool isDetailed) // А что ты от меня хочешь, сука?
    {
        if (isDetailed) GenerateDetailed();
        else GenerateSummary();
    }
}

А вот к чему надо стремиться — это данное зацепление. Чисто, прозрачно, по-мужски. Ты передаёшь ровно те данные, которые нужны: цена, количество, налог. Метод делает свою работу и отдаёт результат. Никаких подвохов.

class OrderProcessor
{
    public decimal CalculateTotal(decimal price, int quantity, decimal taxRate)
    {
        return price * quantity * (1 + taxRate); // Всё честно
    }
}

Так как же сделать, чтобы модули не ебали друг другу мозг?

Первое — инъекция зависимостей. Это как не жениться на конкретной женщине, а договориться, что тебе нужна просто «та, которая готовит». Можешь взять одну, можешь другую. Главное, чтобы интерфейс подходил.

// Раньше было жёстко, как гвоздями прибито
class EmailService
{
    private readonly SmtpClient _client = new SmtpClient(); // Привязан намертво
}

// А теперь — красота
interface INotificationService
{
    void Send(string message);
}

class OrderProcessor
{
    private readonly INotificationService _notifier;

    // Подсовывай что хочешь — смс, email, телеграм. Мне похуй.
    public OrderProcessor(INotificationService notifier)
    {
        _notifier = notifier;
    }
}

Второе — Закон Деметры. Не лезь далеко, не строй цепочки вызовов. Это как не спрашивать у соседа, чтобы он спросил у своего брата, что там его тёща думает про погоду. Иди прямо к источнику.

// Плохо: цепочка, которая может порваться в любом месте
var price = order.Customer.Address.City.GetTaxRate();

// Хорошо: спросил у того, кто в теме
var taxRate = taxService.GetRateForOrder(order);

Третье — события. Модули вообще могут не знать друг о друге. Один крикнул «Заказ создан!» в пустоту, а кто хочет — тот услышит и отреагирует. Инвентарь обновится, нотификация уйдёт, а отправитель даже не в курсе, кто там что делает.

// Крикнул и забыл
eventBus.Publish(new OrderCreatedEvent { OrderId = order.Id });

// Кто-то там подписался и делает своё дело
class InventoryService : IEventHandler<OrderCreatedEvent>
class NotificationService : IEventHandler<OrderCreatedEvent>

В чём профит, спросишь? Да во всём, блядь!

• Тестировать легко — подсунул заглушку и проверил.
• Менять легко — вырвал один модуль, вставил другой, если интерфейс совпадает.
• Понимать легче — всё изолированно, не нужно держать в голове всю вселенную.
• Не сойти с ума, когда через полгода нужно что-то обновить.

Идеал, блядь, это когда ты можешь взять и полностью заменить реализацию какого-нибудь сервиса, поменяв только конфиг в одном месте. А остальной код даже не чихнёт. Вот к этому и стремись, чтобы не было потом мучительно больно.