Что такое слишком много единой ответственности?

Нарушение принципа единственной ответственности (SRP)

Слишком много единой ответственности (или нарушение принципа Single Responsibility Principle — SRP) происходит, когда один класс или метод отвечает за несколько различных аспектов системы. Это нарушение SOLID принципов, которое приводит к сложному, хрупкому и трудному в поддержке коду.

Что такое SRP

Single Responsibility Principle — один из пяти принципов SOLID, сформулированный Робертом Мартином. Он гласит:

"Класс должен иметь одну причину для изменения" или "Класс должен отвечать за одно и только одно"

Пример нарушения SRP

// ПЛОХО: Класс нарушает SRP
public class User {
    private String name;
    private String email;
    private String password;
    
    // Ответственность 1: управление данными пользователя
    public void setPassword(String password) {
        this.password = password;
    }
    
    public String getName() {
        return name;
    }
    
    // Ответственность 2: валидация
    public boolean validateEmail(String email) {
        return email.contains("@");
    }
    
    // Ответственность 3: сохранение в БД
    public void save() {
        if (!validateEmail(email)) {
            throw new IllegalArgumentException("Invalid email");
        }
        // SQL запрос для сохранения
        String sql = "INSERT INTO users (name, email) VALUES ('" + name + "', '" + email + "')";  
        System.out.println("Executing SQL: " + sql);
    }
    
    // Ответственность 4: отправка email
    public void sendWelcomeEmail() {
        System.out.println("Sending email to " + email);
        // SMTP логика
    }
    
    // Ответственность 5: логирование
    public void logActivity(String action) {
        System.out.println("[LOG] User " + name + " did: " + action);
    }
}

Этот класс нарушает SRP, так как отвечает за:

1. Управление данными пользователя
2. Валидацию
3. Персистентность (сохранение в БД)
4. Отправку email
5. Логирование

Проблемы нарушения SRP

1. Сложность и размер класса: Класс с несколькими ответственностями растёт и становится трудным для понимания и поддержки.

2. Высокая связанность: Класс зависит от множества других компонентов (БД, email сервис, логгер), что затрудняет тестирование.

3. Множественные причины для изменения: Если нужно изменить логику валидации, работу с БД или отправку email — нужно менять этот класс. Это увеличивает риск сломать существующий функционал.

4. Трудность в переиспользовании: Нельзя использовать логику валидации отдельно от остального класса.

5. Трудность в тестировании: Нужно мокировать БД и email сервис просто для тестирования логики валидации.

Решение: Разделение ответственности

// ХОРОШО: Разделённые классы с одной ответственностью каждый

// Класс 1: Модель данных пользователя
public class User {
    private String name;
    private String email;
    private String password;
    
    public User(String name, String email, String password) {
        this.name = name;
        this.email = email;
        this.password = password;
    }
    
    public String getName() {
        return name;
    }
    
    public String getEmail() {
        return email;
    }
    
    public String getPassword() {
        return password;
    }
}

// Класс 2: Валидация
public class UserValidator {
    public boolean isValidEmail(String email) {
        return email.matches("^[A-Za-z0-9+_.-]+@(.+)$");
    }
    
    public boolean isValidPassword(String password) {
        return password.length() >= 8;
    }
    
    public void validate(User user) {
        if (!isValidEmail(user.getEmail())) {
            throw new IllegalArgumentException("Invalid email format");
        }
        if (!isValidPassword(user.getPassword())) {
            throw new IllegalArgumentException("Password too short");
        }
    }
}

// Класс 3: Персистентность
public class UserRepository {
    public void save(User user) {
        // Валидация перед сохранением
        new UserValidator().validate(user);
        
        // SQL запрос
        String sql = "INSERT INTO users (name, email) VALUES (?, ?)";  
        System.out.println("Executing SQL: " + sql);
    }
}

// Класс 4: Отправка email
public class EmailService {
    public void sendWelcomeEmail(User user) {
        System.out.println("Sending welcome email to " + user.getEmail());
    }
}

// Класс 5: Логирование
public class Logger {
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
}

// Использование
public class UserRegistration {
    public static void main(String[] args) {
        User user = new User("John", "john@example.com", "password123");
        
        UserValidator validator = new UserValidator();
        validator.validate(user);
        
        UserRepository repository = new UserRepository();
        repository.save(user);
        
        EmailService emailService = new EmailService();
        emailService.sendWelcomeEmail(user);
        
        Logger logger = new Logger();
        logger.log("User registered: " + user.getName());
    }
}

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

• Простота: каждый класс сосредоточен на одной задаче
• Тестируемость: легче написать юнит-тесты для отдельных компонентов
• Переиспользование: компоненты можно использовать в других местах
• Гибкость: изменения в одном компоненте не затрагивают другие
• Низкая связанность: классы слабо зависят друг от друга
• Поддерживаемость: код легче понять и изменять

Как определить, что класс нарушает SRP

• Если сложно дать классу название (требуется "и" в названии)
• Если класс имеет несколько публичных методов, не связанных друг с другом
• Если класс импортирует множество разных зависимостей
• Если есть несколько причин для изменения класса
• Если трудно протестировать класс без мокирования внешних сервисов

Пример: Е-commerce система

// ПЛОХО: Многие ответственности в одном классе
public class OrderProcessor {
    public void processOrder(Order order) {
        // Валидация заказа
        validateOrder(order);
        
        // Расчёт налогов
        double tax = calculateTax(order.getAmount());
        
        // Обработка платежа
        processPayment(order.getCard(), order.getAmount() + tax);
        
        // Сохранение в БД
        saveToDatabase(order);
        
        // Отправка email подтверждения
        sendConfirmationEmail(order.getCustomerEmail());
        
        // Обновление инвентаря
        updateInventory(order.getItems());
    }
}

// ХОРОШО: Разделённые классы
public class OrderService {
    private OrderValidator validator;
    private TaxCalculator taxCalculator;
    private PaymentProcessor paymentProcessor;
    private OrderRepository repository;
    private NotificationService notificationService;
    private InventoryService inventoryService;
    
    public void processOrder(Order order) {
        validator.validate(order);
        double totalWithTax = order.getAmount() + taxCalculator.calculate(order.getAmount());
        paymentProcessor.process(order.getCard(), totalWithTax);
        repository.save(order);
        notificationService.sendConfirmation(order);
        inventoryService.updateItems(order.getItems());
    }
}

Принцип единственной ответственности — основа чистого архитектурного проекта. Его соблюдение делает код гибким, тестируемым и легко поддерживаемым