За что отвечает буква S в принципах SOLID?

Буква S в SOLID означает принцип Single Responsibility Principle (SRP) — Принцип единственной ответственности.

Формулировка:

Класс (или модуль) должен иметь одну и только одну причину для изменения, то есть должен отвечать за одну конкретную задачу или функциональность.

Суть: Цель — создавать узкоспециализированные, слабосвязанные классы. Это упрощает понимание, тестирование, поддержку и изменение кода, так как модификация одной функциональности затрагивает минимальное количество компонентов.

Пример нарушения SRP в C#:

// ❌ Плохо: Класс отвечает и за работу с заказом, и за его логирование, и за отправку email.
public class OrderProcessor
{
    public void Process(Order order)
    {
        // 1. Валидация заказа
        if (order.Total <= 0) throw new Exception("Invalid order");
        // 2. Логика обработки (сохранение в БД, списание запасов)
        _repository.Save(order);
        // 3. Логирование
        File.WriteAllText("log.txt", $"Order {order.Id} processed");
        // 4. Отправка уведомления
        _emailService.SendConfirmation(order);
    }
}

Пример с соблюдением SRP:

// ✅ Хорошо: Ответственность разделена между несколькими классами.
public class OrderValidator { /* Только валидация */ }
public class OrderRepository { /* Только сохранение данных */ }
public class Logger { /* Только логирование */ }
public class NotificationService { /* Только отправка уведомлений */ }

// Основной класс теперь координирует работу, а не выполняет всё сам.
public class OrderProcessor
{
    private readonly OrderValidator _validator;
    private readonly OrderRepository _repository;
    private readonly Logger _logger;
    private readonly NotificationService _notifier;

    public void Process(Order order)
    {
        _validator.Validate(order);
        _repository.Save(order);
        _logger.Log("Order processed", order.Id);
        _notifier.SendConfirmation(order);
    }
}

Почему это важно: Следование SRP напрямую ведёт к более чистому, модульному и устойчивому к изменениям коду, что критически важно в долгосрочной поддержке проекта.