Originally published on phpdesignpatterns.dev — part of the PHP design patterns course. View this lesson on the original site.

Creational patterns in plain English

Creational patterns are about how objects get built. They show up when the act of constructing an object becomes more complicated than the object itself — when there are several valid ways to build it, when the right concrete class depends on context, when construction has dependencies of its own, or when you want to keep the call site clean.

The pressure they relieve

You'll feel the need for a creational pattern when:

• The caller has to know the concrete class to construct, but you'd rather it didn't.
• Object construction takes many parameters and the call site looks like a wall of arguments.
• There are several flavours of the same kind of object (a MysqlOrderRepository vs an InMemoryOrderRepository) and the choice is environmental, not behavioural.
• Construction needs other objects to collaborate (a parser, a validator, a clock) and you don't want every caller to wire them up.

When new SomeClass(...) becomes a smell — too long, too repeated, too coupled to the wrong type — a creational pattern is usually the answer.

The patterns in this family

This course covers five creational patterns:

• Factory Method (chapter 4). A method whose job is to return an object of some interface, letting subclasses (or callers) decide which concrete class is returned. Use it when you want a single named place that decides what to instantiate, and you want that decision to be replaceable.
• Abstract Factory (chapter 19). A family of related Factory Methods bundled into one object. Use it when you have several families of related objects (a MysqlConnection + MysqlQueryBuilder + MysqlMigrator versus the equivalent Postgres… set) and a caller should pick a family, not a class.
• Builder (chapter 9). A small object that assembles a more complex object in steps, often via a fluent interface. Use it when construction has many optional parts (think QueryBuilder, or a multi-step HTTP request).
• Singleton and alternatives (chapter 10). A guarantee that exactly one instance exists. Modern PHP rarely needs the classic Singleton — DI containers solve the same problem better — and this chapter spends most of its time on the alternatives. Worth reading specifically because the pattern is so widely overused.
• Prototype (chapter 27). Building a new object by cloning an existing one rather than constructing from scratch. Use it when constructing from scratch is expensive, or when "give me one like this, but with three things changed" is the natural shape of your callers.

What they have in common

Every creational pattern moves a decision out of the caller and into a named place: a factory, a builder, a clone source. The caller stops asking "how do I build this?" and starts asking "give me a built one." That's the whole shape.

When you don't need them

You don't need a creational pattern when:

• The class has one obvious construction shape and one or two parameters.
• The construction lives entirely inside one file and isn't repeated.
• A direct new SomeClass($x, $y) reads cleanly at the call site.

Don't introduce a UserFactory to wrap new User($email). The factory is overhead until at least one of the pressures above shows up.

The next lesson moves to structural patterns: how to compose objects so that the resulting whole is easier to extend or insulate than the parts would be on their own.

From PHP design patterns — Introduction to design patterns