Singleton (Anti-Pattern)

Also Known As

TL;DR

Explanation

The Singleton pattern guarantees only one instance of a class exists and provides a global access point. While it solves real problems (single database connection, single logger), it introduces global state that makes classes dependent on Singleton internals, complicates testing (can't substitute mock implementations easily), and violates Dependency Inversion. The preferred alternative is using a Dependency Injection container to manage instance lifetime — register services as shared/singleton in the container, inject them via constructors.

Common Misconception

Why It Matters

Common Mistakes

• Using Singleton for services that should be injected — it prevents swapping implementations in tests.
• Singleton that is not thread-safe in async or multi-process contexts.
• Singletons that accumulate state across tests — tests must reset singleton state to be isolated.
• Using Singleton when dependency injection containers already manage instance lifetime.

Code Examples

class Config {
    private static ?self $instance = null;
    private function __construct() {}
    public static function getInstance(): self {
        self::$instance ??= new self();
        return self::$instance;
    }
    // Testing is impossible — can't inject a different Config
    // Shared mutable state across the application
}

// Use DI container to manage single instance instead
// config/app.php (Laravel service container)
$app->singleton(Config::class, fn() => new Config(getenv('APP_ENV')));

// Injected wherever needed — mockable in tests
class AppController {
    public function __construct(private Config $config) {}
}

References

• ↗ https://refactoring.guru/design-patterns/singleton

Tags

Related Terms