Как определишь единую ответственность класса?

📌 Принцип единственной ответственности (SRP)

Принцип единственной ответственности (Single Responsibility Principle, SRP) — это первый из пяти принципов SOLID, который гласит: «Класс должен иметь одну и только одну причину для изменения». Другими словами, класс должен отвечать за одну конкретную задачу или функциональность.

🔍 Критерии определения единой ответственности класса

1. Анализ причин для изменения

• Вопросы для самопроверки:
  • Сколько разных бизнес-требований могут вызвать изменение этого класса?
  • Если изменится способ хранения данных, придется ли менять логику валидации в этом классе?
  • Если изменится формат вывода, затронет ли это внутреннюю бизнес-логику?

2. Выявление сцепленных обязанностей

Нарушение SRP часто проявляется как смешение абстракций:

// ❌ НАРУШЕНИЕ SRP: Класс делает слишком много
class UserManager {
    public function validateData(array $data): bool {
        // Валидация данных пользователя
    }
    
    public function saveToDatabase(array $data): void {
        // Сохранение в базу данных
    }
    
    public function sendWelcomeEmail(User $user): void {
        // Отправка email
    }
    
    public function generateReport(): array {
        // Генерация отчета
    }
}

3. Практические индикаторы нарушения SRP

Признаки "Божественного объекта" (God Object):

• Класс имеет более 300-400 строк кода
• Содержит множество несвязанных методов
• Импортирует разнородные зависимости (ORM, почтовые клиенты, логгеры, валидаторы)

Сигналы в названиях и методах:

• Названия классов с союзами "And", "Or", "Manager", "Processor" (UserRegistrationAndEmailManager)
• Методы, относящиеся к разным уровням абстракции
• Частое изменение класса по разным причинам

🛠️ Пример рефакторинга с применением SRP

// ✅ СОБЛЮДЕНИЕ SRP: Разделение ответственности

// 1. Класс для сущности
class User {
    private string $name;
    private string $email;
    
    public function __construct(string $name, string $email) {
        $this->name = $name;
        $this->email = $email;
    }
    
    public function getName(): string {
        return $this->name;
    }
    
    public function getEmail(): string {
        return $this->email;
    }
}

// 2. Класс для валидации
class UserValidator {
    public function validate(User $user): bool {
        // Только валидация логики
        return filter_var($user->getEmail(), FILTER_VALIDATE_EMAIL) 
            && strlen($user->getName()) > 2;
    }
}

// 3. Класс для работы с хранилищем
class UserRepository {
    public function save(User $user): void {
        // Только сохранение в БД
        // INSERT INTO users ...
    }
}

// 4. Класс для уведомлений
class EmailNotifier {
    public function sendWelcomeEmail(User $user): void {
        // Только отправка email
        mail($user->getEmail(), 'Welcome', 'Welcome message');
    }
}

// 5. Координатор (можно заменить сервисным слоем)
class UserRegistrationService {
    public function __construct(
        private UserValidator $validator,
        private UserRepository $repository,
        private EmailNotifier $notifier
    ) {}
    
    public function registerUser(User $user): void {
        if (!$this->validator->validate($user)) {
            throw new InvalidArgumentException('Invalid user data');
        }
        
        $this->repository->save($user);
        $this->notifier->sendWelcomeEmail($user);
    }
}

🎯 Преимущества соблюдения SRP

Технические benefits:

• Упрощение тестирования — каждый класс тестируется изолированно
• Повышение переиспользуемости — небольшие классы легче комбинировать
• Уменьшение coupling — зависимости становятся явными и управляемыми
• Упрощение рефакторинга — изменения затрагивают минимальный объем кода

Командные benefits:

• Четкое разделение зон ответственности между разработчиками
• Упрощение code review — маленькие классы проще анализировать
• Снижение конфликтов слияния в Git

📊 Метрики и эвристики для оценки

1. Коэффициент связности (Cohesion) — методы класса должны работать с одними и теми же данными
2. Количество публичных методов — обычно 5-10 методов достаточно для одной ответственности
3. Глубина наследования — не более 3-4 уровней, иначе ответственность "размазывается"

💡 Практические рекомендации

Подходы к определению границ:

• Одна бизнес-операция на класс (RegisterUser, ProcessOrder, GenerateInvoice)
• Один способ изменения — если меняется БД, не должна меняться валидация
• Одна техническая ответственность (Logger, Validator, Repository)

Вопросы для регулярного ревью:

• Можно ли описать ответственность класса одным предложением без союза "и"?
• Будут ли изменения в классе происходить по одной причине из backlog?
• Можно ли переиспользовать этот класс в другом проекте без модификаций?

🚨 Распространенные антипаттерны

1. "Утилитные классы" (Utility classes) — собирают несвязанные статические методы
2. "Базовые классы-монстры" — попытки вынести "общую логику" создают сцепление
3. Контроллеры, которые знают о БД, валидации и бизнес-логике

Золотое правило: Если при описании класса вы используете союз "и" — это повод задуматься о разделении ответственности. SRP не означает "один класс — один метод", а означает "один класс — одна причина для изменения".