Creational patterns focus on how objects are created, aiming to make instantiation flexible, decoupled, and appropriate to the situation. The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. Typical implementations use a private constructor so clients cannot freely instantiate the class, combined with a static method that returns the shared instance. Initialization can be eager, with the instance created when the class loads, or lazy, with the instance created on first use. Singleton is appropriate when exactly one instance is genuinely needed, such as a configuration manager, a connection pool, or a logger. However, it introduces global state, which makes testing harder, and it can violate the Single Responsibility Principle because the class manages its own lifecycle. Thread safety requires careful handling, and the pattern is often considered an anti-pattern when overused; a modern alternative is to manage a single shared instance through a dependency injection container.
The Factory Method pattern defines an interface for creating an object but lets subclasses decide which concrete class to instantiate. A creator class declares a factory method that returns a product, and each subclass overrides it to produce a specific variant. This pattern follows the Open/Closed Principle, because new product types can be added by introducing new subclasses without modifying existing code, and it decouples client code from the concrete classes it depends on. It is useful when a class cannot anticipate the class of objects it must create, when subclasses should specify the objects being created, or when you want to localize the knowledge of which class gets instantiated, as in a logistics application where one creator builds trucks and another builds ships.
The Abstract Factory pattern goes a step further by providing an interface for creating families of related objects without specifying their concrete classes. A typical example is a GUI toolkit factory with methods that create buttons, checkboxes, and menus, where concrete factories then produce coordinated sets of widgets for different operating systems. The key distinction from Factory Method is that Abstract Factory uses composition — a factory object creates multiple related products — whereas Factory Method uses inheritance to produce a single product through a subclass. Abstract Factory often relies on Factory Methods internally to construct each product in the family.
The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to create different representations. Instead of a constructor with many parameters, sometimes called the telescoping constructor problem, the client configures a builder step by step and then asks it to produce the final object. This is especially helpful when an object has many optional fields, when construction must follow a particular order, or when different representations of the same kind of object need to be produced, such as complex SQL queries, programmatic UI layouts, or test fixtures with many optional fields. The Prototype pattern takes yet another approach, creating new objects by cloning an existing one rather than invoking a constructor. This avoids the cost of building from scratch and hides the complexities of creating new instances; in Java it relies on the Cloneable interface, while in C++ it is typically implemented with copy constructors. Prototype is most useful when objects differ only slightly or when direct construction is expensive.