creational
Factory Method
Define an interface for creating an object, but let subclasses decide which class to instantiate.
A class often needs to produce objects, but hard-coding new ConcreteType() everywhere welds it to specific implementations. The moment you need a new variant, you are editing existing, tested code and threading conditionals through it. The Factory Method pattern moves that decision behind a single overridable method, so the type being created becomes a pluggable detail rather than a scattered commitment.
A logistics company has a createTransport() method. Road logistics returns a Truck; Sea logistics returns a Ship.
Key Concepts
1
It works by having a base class declare a factory method — sometimes abstract, sometimes with a sensible default — and then calling that method wherever it needs the product. Each subclass overrides the method to return a different concrete type. Crucially, the rest of the base class's logic is written against the product's interface, so it neither knows nor cares which concrete class it received. Adding a new product is a matter of writing a new subclass, not touching the existing flow.
2
This pattern shines when you don't know ahead of time which class to instantiate, when subclasses should control what gets created, or when you are building a framework whose users plug in their own implementations. The main cost is a proliferation of small subclasses — if the only thing varying is the constructor call, the extra hierarchy can feel heavy, and a simple parameterised "static factory" method may be enough. Factory Method earns its keep when creation logic is non-trivial or when the creator class has real behaviour built on top of the product.