Introduction to Creational Design Patterns

Creational design patterns abstract the instantiation process, making a system independent of how its objects are created, composed, and represented. Among the GoF patterns, Singleton and Factory Method are two of the most frequently encountered, yet they solve fundamentally different problems. Singleton controls the number of instances, while Factory Method delegates the responsibility of choosing which concrete class to instantiate. Misapplying either pattern leads to rigid, hard-to-test code or unnecessary complexity. This article examines each pattern in depth, clarifies their appropriate contexts, and provides actionable guidance for engineers deciding between them.

Singleton Pattern in Detail

The Singleton pattern restricts a class to a single instance and provides a global point of access to that instance. It is one of the simplest patterns but also one of the most controversial due to its impact on testability and coupling.

Core Characteristics

  • Single instance guarantee: The private constructor prevents external instantiation. A static method (often getInstance()) returns the sole instance.
  • Global access: The instance is accessible from anywhere in the application, often via a public static variable or method.
  • Lazy or eager initialization: The instance can be created at class loading time (eager) or deferred until first request (lazy).

When Singleton Is Appropriate

  • Shared resources that must be coordinated: Configuration managers, thread pools, connection pools, logging services, and hardware interface drivers often require exactly one controller.
  • Global state that should not be duplicated: Cache managers, file system abstraction layers, or window managers in GUI frameworks.
  • Resource-intensive objects: Objects that are expensive to create and reused across the system benefit from a single instance.

Implementation Considerations

Thread safety is the most common pitfall. A naive implementation that checks for null and then creates the instance can produce multiple instances in multithreaded environments. Solutions include double-checked locking with volatile, static inner class (Bill Pugh singleton), or an enum-based singleton in Java. In Python, thread-safe initialization using threading.Lock is standard. The choice between eager and lazy initialization depends on whether the singleton is guaranteed to be used and whether its creation is heavy.

Criticism and Pitfalls

Singletons are often considered anti‑patterns because they introduce global state, which makes unit testing difficult—tests become order-dependent and hard to isolate. They also hide dependencies; a class that calls Singleton.getInstance() directly is tightly coupled to the singleton’s concrete class. Modern practice recommends using dependency injection to supply the singleton as a shared instance, allowing substitution with mocks in tests. Additionally, singletons in a distributed system (e.g., microservices) are meaningless unless scoped per process—a single instance across network nodes requires additional coordination.

Factory Method Pattern in Detail

The Factory Method pattern defines an interface for creating an object but lets subclasses decide which class to instantiate. It shifts the responsibility of object creation from the client to a factory method, promoting the open/closed principle.

Core Characteristics

  • Encapsulated creation logic: The client code does not know the concrete class; it works through an abstract product type.
  • Extensibility: New product types can be added by creating new concrete factories without modifying existing client code.
  • Deferred instantiation: The exact class to instantiate is determined at runtime, based on input, configuration, or context.

When Factory Method Is Appropriate

  • Families of related objects: When a system needs to work with multiple product variations that share a common interface—e.g., different database drivers, document export formats, or UI themes.
  • Decoupling client code from concrete implementations: The client calls the factory method and receives an object conforming to an abstract interface. Changes to concrete classes do not affect the client.
  • Configuration-driven creation: The application can decide at startup which concrete factory to use based on a configuration file, environment variable, or runtime condition.

Implementation Considerations

A typical Factory Method uses an abstract Creator class that declares the factory method (often abstract). Concrete creators override this method to instantiate specific products. In languages without inheritance (e.g., JavaScript), the factory can be a function or a closure. The pattern works well with dependency injection containers that can substitute implementations. A common variant is the static factory method (e.g., LocalDate.of() in Java), but this is not the same as the GoF Factory Method pattern—it’s a simpler idiom that does not involve subclassing.

Real-World Example: Document Converter

Consider an application that converts documents between formats. An abstract DocumentConverter interface defines a convert() method. The factory method createConverter(String format) returns a PdfConverter, WordConverter, or HtmlConverter based on the input extension. Adding a new format (e.g., Markdown) requires only a new converter class and updating the factory method—no changes to the conversion pipeline.

Direct Comparison: Singleton vs. Factory Method

Although both are creational patterns, their goals and trade-offs are nearly orthogonal.

Aspect Singleton Factory Method
Primary goal Ensure a single instance Encapsulate object creation
Instance count Exactly one Many instances, but created through a factory
Control over class selection Not relevant (always same class) Subclasses or runtime logic choose the concrete class
Impact on maintainability Can increase coupling (global access) Reduces coupling (client depends on abstraction)
Testability Often problematic (global state) Good, as factories can be mocked
Extensibility Limited (hard to subclass a singleton) High (new products via new factories)

Choose Singleton when your overriding concern is instance uniqueness and global coordination—for example, a logging service that must serialize writes to a single file. Choose Factory Method when your focus is on decoupling object creation from client code and allowing the system to grow with new product variants—for example, a GUI toolkit that needs to render native buttons on different operating systems.

When They Overlap (and When to Use Neither)

It is common to see a Singleton used as a Factory (e.g., a singleton ObjectFactory that knows how to create various objects). This approach combines both patterns but inherits the drawbacks of global state. A better alternative is to inject the factory dependency and keep the factory itself as a plain class—the singleton is often the wrong choice for the factory. If the goal is to share a factory instance across the application, a dependency injection container can manage that instance’s lifecycle without forcing a Singleton pattern on the factory implementation.

Practical Considerations for Modern Applications

Testing and Dependency Injection

Both patterns interact with testing in different ways. Singletons are notoriously difficult to replace in unit tests. A common workaround is to introduce an interface for the singleton and provide a test double, but that undermines the pattern’s simplicity. Factory Methods, on the other hand, are easily replaced by providing a mock factory in tests. In modern frameworks (Spring, Unity, Guice), the container handles singleton scoping automatically, removing the need to implement the pattern manually.

Concurrency and Distributed Systems

Singleton breaks down in distributed systems because “single instance” cannot span multiple processes or nodes. For shared resources across microservices, engineers use shared databases, caches like Redis, or leader election—not the Singleton pattern. Factory Method remains applicable even in distributed contexts; it simply creates objects within each service boundary.

Combining Patterns for Real-World Solutions

Many production systems combine these patterns intelligently. For instance, a Singleton connection pool might use a Factory Method to create different types of connections (e.g., read-only vs. read-write). The singleton ensures one pool per application, while the factory method handles the creation of connection objects. Another example: a singleton document generator that delegates to a factory method for creating format-specific renderers.

Common Mistakes to Avoid

  • Using Singleton when a factory would suffice: If you only want a single instance of a class for performance reasons, dependency injection with a singleton scope is cleaner than a global accessor.
  • Using Factory Method when object creation is trivial and fixed: If the object type never changes and has no subclasses, a simple constructor is clearer.
  • Tight coupling between factory and product families: Avoid putting configuration or business logic inside the factory method that should belong elsewhere.
  • Forgetting thread safety in singletons: In server environments, a non-thread-safe singleton can produce corrupt state under load.

Conclusion

Singleton and Factory Method serve fundamentally different roles in software design. Singleton enforces a single instance for global coordination; Factory Method abstracts object creation to support runtime variability and extensibility. Choosing between them requires evaluating whether your primary concern is instance uniqueness or creation flexibility. Neither pattern is a silver bullet—each introduces trade-offs in testability, coupling, and complexity. By understanding their strengths and limitations, engineers can apply them deliberately, often in combination with dependency injection and modern frameworks, to build scalable and maintainable systems.

For further reading, see the classic GoF patterns on Refactoring.Guru and Factory Method. Also consider Martin Fowler’s analysis of Registry as an alternative to Singleton, and the Wikipedia article on Factory Method pattern for language-specific implementations.