Creator

“Who should be responsible for creating a new instance of some class?” – Craig Larman

Assign class B the responsibility to create an instance of class A if one of these is true:

When to use

When you need to create a new object and are deciding where that new keyword should live.

Low Coupling: If B already depends on A (contains it), letting B create A doesn’t add a new dependency.
Clarity: It clarifies ownership and lifecycle management.

Objects are created in random “Utility” classes or high-level controllers that have no business knowing about the specific implementation details of the created object.
Passing huge number of arguments to a constructor because the creator doesn’t have the data.

Creating objects scatteredly increases coupling. If every class instantiates every other class, changing a constructor signature becomes a nightmare.

Let the “container” or “owner” create the “contained” or “owned” objects.

A mother “creates” a child. A factory “creates” a product. A Folder “creates” a File (conceptually, the file belongs to the folder).

Pros	Cons
Supports low coupling Logical flow	Can lead to high coupling if used stiffly (vs Dependency Injection)

Factory Pattern: A more complex version of Creator when creation logic is complicated.
DI (Dependency Injection): Often prefers injecting factories or instances rather than direct creation, but Creator guides where that injection/factory placement might logically belong in a domain model.