Почему Singleton является антипаттерном?

Почему Singleton является антипаттерном

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

Singleton нарушает SOLID принципы, усложняет тестирование и скрывает зависимости. Вместо Singleton используй Dependency Injection с контейнером (Spring, Guice).

1. Скрывает зависимости (Dependency Inversion Principle)

Проблема с Singleton:

public class Logger {
    private static Logger instance;
    
    private Logger() {}
    
    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }
    
    public void log(String msg) {
        System.out.println(msg);
    }
}

public class UserService {
    public void createUser(User user) {
        // Скрытая зависимость! Где Logger? Откуда он берется?
        Logger.getInstance().log("Creating user: " + user.getName());
    }
}

Проблемы:

• Зависимость от Logger скрыта в теле метода
• Невозможно понять, какие зависимости нужны UserService, только посмотрев сигнатуру
• Нарушает Single Responsibility Principle: UserService отвечает и за логирование

Правильный способ (Dependency Injection):

public class Logger {
    public void log(String msg) {
        System.out.println(msg);
    }
}

public class UserService {
    private Logger logger;  // Явная зависимость!
    
    public UserService(Logger logger) {  // Инжекция через конструктор
        this.logger = logger;
    }
    
    public void createUser(User user) {
        logger.log("Creating user: " + user.getName());
    }
}

Преимущества:

• Зависимость явна (видна в сигнатуре конструктора)
• Легко тестировать (подаю mock Logger)
• Соответствует DIP (Dependency Inversion Principle)

2. Усложняет тестирование (Testability)

С Singleton (невозможно тестировать):

public class UserServiceTest {
    @Test
    public void testCreateUser() {
        UserService service = new UserService();
        service.createUser(new User("John"));
        
        // Как проверить, что Logger.getInstance() был вызван?
        // Как подменить Logger на Mock Logger?
        // НЕВОЗМОЖНО! Logger глобальный singleton!
    }
}

С Dependency Injection (легко тестировать):

public class UserServiceTest {
    @Test
    public void testCreateUser() {
        Logger mockLogger = mock(Logger.class);
        UserService service = new UserService(mockLogger);
        
        service.createUser(new User("John"));
        
        // Проверяю, что logger был вызван правильно
        verify(mockLogger).log(contains("John"));
    }
}

3. Нарушает Single Responsibility Principle

Проблема:

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {}  // Приватный конструктор
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();  // Singleton отвечает за создание себя!
        }
        return instance;
    }
    
    // + еще бизнес-логика
    public void doSomething() { ... }
}

Singleton отвечает за две вещи:

1. Создание единственного экземпляра (Infrastructure)
2. Бизнес-логика (Domain)

Это нарушает SRP! Правильно разделить.

4. Проблемы с многопоточностью

Проблема 1: Race condition в Singleton

public class Singleton {
    private static Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {  // Проверка
            instance = new Singleton();  // Создание
            // RACE CONDITION!
            // Два потока могут оба пройти проверку и создать два экземпляра
        }
        return instance;
    }
}

Решение (Lazy Bill Pugh):

public class Singleton {
    private static class SingletonHolder {
        public static final Singleton INSTANCE = new Singleton();
    }
    
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;  // Thread-safe из коробки
    }
}

Но это усложнение! Лучше использовать Spring:

@Configuration
public class AppConfig {
    @Bean
    public Singleton singleton() {
        return new Singleton();  // Spring сам управляет:
    }                            // - Singleton scope
                                 // - Thread-safety
                                 // - Lifecycle
}

5. Проблемы с состоянием

Проблема: глобальное состояние

public class ApplicationState {
    private static ApplicationState instance;
    private String currentUser;
    private List<String> logs = new ArrayList<>();
    
    public static ApplicationState getInstance() {
        if (instance == null) {
            instance = new ApplicationState();
        }
        return instance;
    }
    
    public void setCurrentUser(String user) {
        this.currentUser = user;
    }
}

// Проблемы в тестах:
@Test
first() {
    ApplicationState.getInstance().setCurrentUser("Alice");
    // ... test Alice
}

@Test
second() {
    // currentUser все еще "Alice" от предыдущего теста!
    // State утекает между тестами
}

С DI + Spring scope:

@Component
@Scope("request")  // Новый экземпляр на каждый request
public class UserContext {
    private String currentUser;
    // No state leaking!
}

6. Нарушает Open/Closed Principle

С Singleton (невозможно расширить):

public class DatabaseConnection {
    private static DatabaseConnection instance;
    
    private DatabaseConnection() {}
    
    public static DatabaseConnection getInstance() {
        return instance;
    }
    
    public void connect() {
        // Hardcoded PostgreSQL
        Class.forName("org.postgresql.Driver");
    }
}

// Хочу использовать MySQL в другом проекте?
// НЕВОЗМОЖНО! DatabaseConnection жестко привязан к PostgreSQL

С Interface + DI (легко расширить):

public interface Database {
    void connect();
}

public class PostgreSQL implements Database {
    public void connect() { ... }
}

public class MySQL implements Database {
    public void connect() { ... }
}

public class UserService {
    private Database db;  // Зависит от абстракции!
    
    public UserService(Database db) {
        this.db = db;
    }
}

// Spring DI подберет реализацию:
@Configuration
public class Config {
    @Bean
    public Database database() {
        return new PostgreSQL();  // В production
    }
    
    @Bean
    public Database testDatabase() {
        return new MockDatabase();  // В тестах
    }
}

7. Сложность с классной загрузкой (ClassLoader)

Проблема в распределенных системах:

// В разных ClassLoaders могут существовать разные Singleton экземпляры!
// Это особенно проблемно в:
// - Приложениях с несколькими ClassLoaders
// - Serialization/Deserialization
// - Spring контейнерах

8. Альтернатива: когда действительно нужен один экземпляр

Spring beans по умолчанию Singleton:

@Configuration
public class AppConfig {
    @Bean
    public Logger logger() {
        return new Logger();  // Spring гарантирует: только один экземпляр
    }
}

@Service
public class UserService {
    @Autowired  // Всегда один и тот же Logger
    private Logger logger;
}

Spring управляет:

• Созданием: по правилам (Singleton, Prototype, Request scope)
• Инъекцией: автоматической подачей зависимостей
• Lifetime: контролируемый жизненный цикл

Когда Singleton может быть оправдан

1. Immutable Singleton (нет состояния):

public final class Constants {
    public static final String VERSION = "1.0";
    public static final int MAX_USERS = 1000;
    
    private Constants() {}  // Невозможно создать экземпляр
}

1. Enum Singleton (самый безопасный способ):

public enum Logger {
    INSTANCE;
    
    public void log(String msg) {
        System.out.println(msg);
    }
}

Logger.INSTANCE.log("Message");  // Используется

1. Factory (если нужен контроль над созданием):

public class ConnectionPool {
    private static ConnectionPool instance;
    private List<Connection> connections;
    
    private ConnectionPool(int size) {
        this.connections = createConnections(size);
    }
    
    public static synchronized ConnectionPool getInstance(int size) {
        if (instance == null) {
            instance = new ConnectionPool(size);
        }
        return instance;
    }
}

Итог

Вывод: Используй Dependency Injection контейнер (Spring, Guice) вместо Singleton. Это современный, более гибкий и тестируемый подход к управлению жизненным циклом объектов.