Какой принцип SOLID нарушает god object?

God Object и принцип SOLID

Краткий ответ

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

Что такое God Object

God Object (объект-бог) — это анти-паттерн, когда один класс:

• Содержит слишком много ответственности
• Знает слишком много о других классах
• Имеет сотни методов
• Сложный и трудный для тестирования

Пример God Object

// ❌ ПЛОХО - God Object
@Entity
@Service
public class UserManager { // Какое имя! "Manager" - красный флаг
    
    @Autowired
    private UserRepository repo;
    
    @Autowired
    private EmailService emailService;
    
    @Autowired
    private PaymentService paymentService;
    
    @Autowired
    private NotificationService notificationService;
    
    // Это класс знает о ВСЕ
    
    // 1. Создание и управление пользователями
    public User createUser(String email, String password) { ... }
    public User updateUser(Long id, UserDto dto) { ... }
    public void deleteUser(Long id) { ... }
    public User findById(Long id) { ... }
    
    // 2. Аутентификация
    public boolean authenticate(String email, String password) { ... }
    public String generateToken(User user) { ... }
    public boolean validateToken(String token) { ... }
    
    // 3. Отправка писем
    public void sendWelcomeEmail(User user) { ... }
    public void sendPasswordResetEmail(User user) { ... }
    public void sendNotificationEmail(User user) { ... }
    public void sendBirthdayEmail(User user) { ... }
    
    // 4. Управление подпиской
    public void subscribePremium(Long userId) { ... }
    public void unsubscribe(Long userId) { ... }
    public void renewSubscription(Long userId) { ... }
    
    // 5. Платежи
    public void processPayment(Long userId, BigDecimal amount) { ... }
    public void refundPayment(Long userId, String transactionId) { ... }
    
    // 6. Профиль
    public void updateProfile(Long userId, ProfileDto dto) { ... }
    public ProfileDto getProfile(Long userId) { ... }
    public void uploadAvatar(Long userId, File file) { ... }
    
    // 7. Логирование и аудит
    public void logActivity(Long userId, String action) { ... }
    public void auditAction(Long userId, String action, Object details) { ... }
    
    // ... ещё 50+ методов
}

Проблемы этого класса:

1. Нарушает Single Responsibility — отвечает за 7+ разных задач
2. Сложный для тестирования — нужно мокировать все зависимости
3. Высокий coupling — изменение одной части ломает другие
4. Трудно переиспользовать — нельзя использовать отдельно
5. Сложность — 1000+ строк кода

Как исправить: разделение ответственности

// ✅ ХОРОШО - Каждый класс отвечает за одно

// 1. Управление пользователями
@Service
public class UserService {
    @Autowired
    private UserRepository repo;
    
    public User createUser(String email, String password) { ... }
    public User updateUser(Long id, UserDto dto) { ... }
    public void deleteUser(Long id) { ... }
    public User findById(Long id) { ... }
}

// 2. Аутентификация
@Service
public class AuthenticationService {
    @Autowired
    private JwtTokenProvider tokenProvider;
    
    public boolean authenticate(String email, String password) { ... }
    public String generateToken(User user) { ... }
    public boolean validateToken(String token) { ... }
}

// 3. Отправка писем
@Service
public class EmailService {
    @Autowired
    private EmailProvider emailProvider;
    
    public void sendWelcomeEmail(User user) { ... }
    public void sendPasswordResetEmail(User user) { ... }
    public void sendNotificationEmail(User user) { ... }
}

// 4. Управление подпиской
@Service
public class SubscriptionService {
    @Autowired
    private SubscriptionRepository repo;
    
    public void subscribePremium(Long userId) { ... }
    public void unsubscribe(Long userId) { ... }
    public void renewSubscription(Long userId) { ... }
}

// 5. Платежи
@Service
public class PaymentService {
    @Autowired
    private PaymentGateway gateway;
    
    public void processPayment(Long userId, BigDecimal amount) { ... }
    public void refundPayment(Long userId, String transactionId) { ... }
}

// 6. Профиль пользователя
@Service
public class ProfileService {
    @Autowired
    private ProfileRepository repo;
    @Autowired
    private StorageService storage;
    
    public void updateProfile(Long userId, ProfileDto dto) { ... }
    public ProfileDto getProfile(Long userId) { ... }
    public void uploadAvatar(Long userId, File file) { ... }
}

// 7. Логирование и аудит
@Service
public class AuditService {
    @Autowired
    private AuditRepository repo;
    
    public void logActivity(Long userId, String action) { ... }
    public void auditAction(Long userId, String action, Object details) { ... }
}

Использование разделённых сервисов

// UserController использует несколько сервисов
@RestController
@RequestMapping("/api/v1/users")
public class UserController {
    
    @Autowired
    private UserService userService;
    
    @Autowired
    private AuthenticationService authService;
    
    @Autowired
    private EmailService emailService;
    
    @Autowired
    private SubscriptionService subscriptionService;
    
    @PostMapping("/register")
    public ResponseEntity<UserDto> register(@RequestBody RegisterRequest req) {
        // Каждый сервис делает одно
        User user = userService.createUser(req.getEmail(), req.getPassword());
        emailService.sendWelcomeEmail(user);
        subscriptionService.subscribePremium(user.getId());
        return ResponseEntity.ok(UserDto.from(user));
    }
}

Признаки God Object

Почему это нарушение Single Responsibility

Single Responsibility Principle гласит:

Класс должен иметь ОДНУ причину для изменения

// ❌ GOD OBJECT - множество причин для изменения
public class UserManager {
    // Изменится, если:
    // 1. Меняется логика создания пользователя
    // 2. Меняется алгоритм токена
    // 3. Меняется формат письма
    // 4. Меняется способ оплаты
    // ... и так далее
}

// ✅ ПРАВИЛЬНО - одна причина для изменения
@Service
public class UserService {
    // Изменится ТОЛЬКО если меняется логика пользователей
}

@Service
public class PaymentService {
    // Изменится ТОЛЬКО если меняется логика платежей
}

Правила для избежания God Object

1. Одна ответственность на класс

   // ❌ Плохо
   class User { /* сохранение + валидация + преобразование */ }
   
   // ✅ Хорошо
   class User { /* только данные */ }
   class UserValidator { /* валидация */ }
   class UserMapper { /* преобразование */ }
   

2. Максимум 5-7 зависимостей на сервис

   // ❌ Слишком много
   @Service
   public class UserService {
       @Autowired private UserRepository repo;
       @Autowired private EmailService email;
       @Autowired private PaymentService payment;
       // ... ещё 10
   }
   
   // ✅ Правильно
   @Service
   public class UserService {
       @Autowired private UserRepository repo; // 1-3 зависимости
   }
   

3. Используй composition вместо наследования

   // ✅ Хорошо - композиция
   @Service
   public class RegistrationService {
       @Autowired private UserService userService;
       @Autowired private EmailService emailService;
       @Autowired private SubscriptionService subService;
       
       public void register(User user) {
           userService.create(user);
           emailService.sendWelcome(user);
           subService.createTrial(user);
       }
   }
   

Выводы

1. God Object нарушает Single Responsibility — самый критичный принцип
2. Признаки: много методов, много зависимостей, имена вроде Manager
3. Решение: разбить на несколько специализированных сервисов
4. Преимущества разделения:
   • Легче тестировать
   • Легче понять
   • Легче менять
   • Легче переиспользовать
5. Правило: если сложно назвать класс одним словом — возможно это God Object