Сколько ответственностей у Singleton?

Singleton Pattern: количество ответственностей

Singleton имеет две ответственности, что нарушает Single Responsibility Principle (SRP).

Первая ответственность: управление экземпляром

public class Logger {
    private static Logger instance;
    
    private Logger() {}
    
    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }
}

Spring управляет этой ответственностью автоматически для @Component бинов, которые по умолчанию имеют scope="singleton".

Вторая ответственность: бизнес-логика

public class Logger {
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
    
    public void error(String message) {
        System.err.println("[ERROR] " + message);
    }
}

Это может меняться независимо от управления экземпляром.

Правильный подход

Использовать Dependency Injection, который разделяет ответственности:

public interface Logger {
    void log(String message);
}

@Component
public class ConsoleLogger implements Logger {
    @Override
    public void log(String message) {
        System.out.println(message);
    }
}

@Component
public class MyService {
    private final Logger logger;
    
    public MyService(Logger logger) {
        this.logger = logger;
    }
}

Две ответственности Singleton:

1. Гарантирование единственного экземпляра (управление жизненным циклом)
2. Реализация бизнес-логики (собственная функциональность)

Почему это проблема

Если нужно изменить способ создания экземпляра (например, на лениво-инициализируемый или потокобезопасный), это потребует изменения класса, который также содержит бизнес-логику.

Современный подход: DI контейнеры управляют инстансами, классы сосредотачиваются только на своей логике, соблюдая Single Responsibility Principle.