Singleton Pattern

You are a software architect. The user wants to implement the Singleton pattern to ensure a class has only one instance and provide a global point of access to it.

What to check first

• Verify your language supports static variables or class variables (Java, Python, C#, JavaScript all do)
• Determine if you need thread-safety (critical for multi-threaded environments like Java, C++)
• Check if your codebase uses dependency injection (which may make Singleton unnecessary)

Steps

1. Create a class with a private constructor to prevent instantiation from outside
2. Add a static variable to hold the single instance of the class
3. Create a static method (typically named getInstance()) that returns the instance
4. In the static method, check if the instance is null and create it only once
5. For thread-safe implementations, use synchronized keyword (Java) or lock mechanisms
6. Test that multiple calls to getInstance() return the exact same object reference
7. Verify the private constructor prevents new ClassName() from compiling or executing
8. Document when the instance is first created (lazy vs. eager initialization)

Code

public class DatabaseConnection {
    // Static variable to hold the single instance
    private static DatabaseConnection instance;
    
    // Private constructor to prevent instantiation
    private DatabaseConnection() {
        System.out.println("DatabaseConnection instance created");
    }
    
    // Thread-safe getInstance method using synchronized
    public static synchronized DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }
    
    public void connect() {
        System.out.println("Connected to database");
    }
    
    public void disconnect() {
        System.out.println("Disconnected from database");
    }
}

// Usage example
public class Application {
    public static void main(String[] args) {
        // Both calls return the exact same instance
        DatabaseConnection db1 = DatabaseConnection.getInstance();
        DatabaseConnection db2 = DatabaseConnection.getInstance();
        
        db1.connect();
        
        // This proves they're the same object
        System.out.println(db1 == db2); // Output: true
        
        db2.disconnect();
    }
}

Pitfalls

• Forgetting the private constructor — if you omit it, external code can call new ClassName() and create multiple instances, breaking the pattern entirely
• Not using synchronized in multi-threaded code — without synchronization, two threads can both pass the if (instance == null) check and create two separate instances simultaneously
• Using Singleton when dependency injection is better — Singleton makes testing harder because you can't easily mock or replace the instance; consider if a dependency injection container would be more appropriate
• Lazy initialization delays first use — the first call to getInstance() may have noticeable latency; if that matters, use eager initialization by creating the instance as a static field directly

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change