Стоит ли создавать отдельный класс для реализации одной функции?

Нужен ли отдельный класс для одной функции?

Ответ не однозначен и зависит от контекста. Но в большинстве случаев - нет, не стоит создавать отдельный класс для одной функции.

Принцип YAGNI (You Arent Gonna Need It)

Это одна из основных концепций clean code:

// ❌ ПЛОХО - избыточная сложность
public class EmailValidator {
    public boolean validate(String email) {
        return email.matches("^[A-Za-z0-9+_.-]+@(.+)$");
    }
}

// ✅ ХОРОШО - простая утилита
public final class ValidationUtils {
    private ValidationUtils() {}
    
    public static boolean isValidEmail(String email) {
        return email != null && 
               email.matches("^[A-Za-z0-9+_.-]+@(.+)$");
    }
}

Создание класса для одного метода приводит к:

• Излишней сложности
• Большему количеству файлов для поддержки
• Усложнению навигации по коду

Когда СТОИТ создать отдельный класс

1. Интерфейс с множественной реализацией

// ✅ Здесь класс имеет смысл
public interface PaymentProcessor {
    PaymentResult process(Payment payment);
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public PaymentResult process(Payment payment) {
        // реализация для кредитных карт
    }
}

public class PayPalProcessor implements PaymentProcessor {
    @Override
    public PaymentResult process(Payment payment) {
        // реализация для PayPal
    }
}

Здесь каждый класс имеет одну функцию, но это необходимо для полиморфизма.

2. Сложная логика с состоянием

// ✅ Класс имеет смысл, потому что есть состояние
public class RequestBuilder {
    private String url;
    private Map<String, String> headers = new HashMap<>();
    private String body;
    
    public RequestBuilder withUrl(String url) {
        this.url = url;
        return this;
    }
    
    public RequestBuilder withHeader(String key, String value) {
        headers.put(key, value);
        return this;
    }
    
    public HttpRequest build() {
        return new HttpRequest(url, headers, body);
    }
}

3. Основная ответственность (Single Responsibility Principle)

// ✅ Класс отвечает за преобразование
public class UserToDto {
    public UserDTO convert(User user) {
        return new UserDTO(
            user.getId(),
            user.getEmail(),
            user.getCreatedAt()
        );
    }
}

// Или как статический метод в утилите
public final class UserDtoConverter {
    private UserDtoConverter() {}
    
    public static UserDTO toDTO(User user) {
        // ...
    }
}

Альтернативные подходы

1. Статический метод в утилите

public final class StringUtils {
    private StringUtils() {}  // не позволяет создать экземпляр
    
    public static String capitalize(String str) {
        if (str == null || str.isEmpty()) return str;
        return str.substring(0, 1).toUpperCase() + 
               str.substring(1).toLowerCase();
    }
}

// Использование
String result = StringUtils.capitalize("hello");

2. Функциональный интерфейс и лямбда

// Функциональный интерфейс для одной операции
@FunctionalInterface
public interface Transformer<T, R> {
    R transform(T input);
}

// Использование с лямбдой
Transformer<String, Integer> parseToInt = Integer::parseInt;
int result = parseToInt.transform("42");

3. Вложенный класс (если функция относится к одному контексту)

public class UserService {
    public User createUser(UserRequest request) {
        UserValidator validator = new UserValidator();
        validator.validate(request);
        return new User(request);
    }
    
    private static class UserValidator {
        void validate(UserRequest request) {
            if (request.getEmail() == null) {
                throw new IllegalArgumentException("Email required");
            }
        }
    }
}

Практический пример

// ❌ НЕПРАВИЛЬНО - класс не нужен
public class GetSquareRoot {
    public double calculate(double number) {
        return Math.sqrt(number);
    }
}

// ✅ ПРАВИЛЬНО - просто используй Math
double result = Math.sqrt(16); // 4.0

// ❌ НЕПРАВИЛЬНО - один метод
public class PasswordEncoder {
    public String encode(String password) {
        return BCrypt.hashpw(password, BCrypt.gensalt());
    }
}

// ✅ ПРАВИЛЬНО - группируй в утилите
public final class SecurityUtils {
    public static String encodePassword(String password) {
        return BCrypt.hashpw(password, BCrypt.gensalt());
    }
    
    public static boolean verifyPassword(String password, String hash) {
        return BCrypt.checkpw(password, hash);
    }
}

Критерии для принятия решения

Создавай класс, если:

• Функция может иметь несколько реализаций → интерфейс + реализации
• Функция часть более крупного логического целого
• Функция поддерживает состояние или конфигурацию
• Следуя паттернам (Builder, Factory, Strategy)

Не создавай класс, если:

• Одна изолированная утилита-функция
• Нет состояния или вариативности
• Функция не требует объектно-ориентированных концепций
• Можно использовать статический метод или утилиту

Вывод

Слоган KISS (Keep It Simple, Stupid) - создавай абстракции только когда они действительно нужны. Один класс с одним методом часто - это усложнение, а не архитектура. Начни с простого решения, а когда возникнет необходимость в расширении - тогда создавай новые классы.