Почему размещение бизнес-логики в конструкторе считается плохой практикой?

Размещение нетривиальной бизнес-логики в конструкторе нарушает ключевые принципы проектирования и считается антипаттерном.

Основные проблемы:

1. Нарушение принципа единственной ответственности (SRP): Конструктор должен отвечать только за инициализацию объекта (валидацию аргументов, установку полей). Бизнес-логика — это другая ответственность.
2. Сложность тестирования: Конструктор с логикой, зависящей от внешних сервисов (БД, API), невозможно протестировать изолированно без создания сложных мок-объектов или полноценного контекста.
3. Проблемы с наследованием: Если класс будет унаследован, логика в конструкторе родителя выполнится до инициализации полей потомка, что может привести к NullPointerException.
4. Непредсказуемость и побочные эффекты: Создание объекта не должно иметь побочных эффектов (например, отправлять письма или списывать деньги).

Пример плохого подхода:

public class UserRegistration {
    private EmailService emailService;

    public UserRegistration(UserData data, EmailService emailService) {
        this.emailService = emailService;
        // Бизнес-логика ВНУТРИ конструктора
        if (!data.isEmailValid()) {
            throw new ValidationException("Invalid email");
        }
        this.emailService.sendWelcomeEmail(data.getEmail()); // Побочный эффект!
    }
}

Правильные альтернативы:

1. Фабричный метод или отдельный сервис:

   public class UserRegistrationService {
       public UserRegistration createRegistration(UserData data) {
           validate(data); // Логика валидации вынесена
           UserRegistration reg = new UserRegistration(data);
           // Действия с побочными эффектами — после создания
           emailService.sendWelcomeEmail(data.getEmail());
           return reg;
       }
       private void validate(UserData data) { ... }
   }

2. Паттерн Builder: Сложная инициализация с проверками выносится в отдельный класс-строитель.
3. Метод инициализации (init): Если логика должна выполняться при создании бина Spring, используйте аннотацию @PostConstruct на отдельном методе, а не в конструкторе.

Вывод: Конструктор должен быть простым и предсказуемым. Бизнес-логику следует выносить в методы сервисных классов.