You start with email only. Then SMS, push, Slack, WhatsApp… Each channel adds a branch to the same service. The class becomes a control tower that knows every concrete type.
Tight coupling: one service points at every concrete notification class
Adding a sixth channel means editing NotificationService again — regression risk and merge conflicts.
Extract creation into one class. The service asks the factory; it does not build new EmailNotification() itself. Better separation — but the factory still tends toward a switch that grows forever.
class SimpleNotificationFactory {
public static Notification createNotification(String type) {
return switch (type) {
case "EMAIL" -> new EmailNotification();
case "SMS" -> new SMSNotification();
case "PUSH" -> new PushNotification();
default -> throw new IllegalArgumentException("Unknown type");
};
}
}
One factory → many product types (still one place to edit)
Each new notification type still means changing the factory’s switch. You are not yet open for extension without modification — you only moved the problem.
Classic Factory Method class diagram
Notification) with send()EmailNotification, SMSNotification, …send() calls createNotification() then uses the product)
Creator defines the flow; subclass decides the product
send() on the CreatorcreateNotification() — resolved on the concrete subclassNotification (interface type)notification.send(message)Add WhatsApp by introducing two new classes — product + creator — and wiring the new creator where needed. No edits to existing creators or the abstract Creator.
Products: Document (PDF, HTML, CSV). Creators: PdfExportCreator, …
Shared export() in the abstract Creator walks header → rows → footer once; each Document supplies format-specific strings.
Export system — creators and products paired
Product family: same deliver(), different vehicles
Without Factory Method, client code might use if (type == 1) new TwoWheeler() else new FourWheeler() — tight coupling and mixed responsibilities.
With VehicleFactory and factories like TwoWheelerFactory / FourWheelerFactory, the client only uses Vehicle v = factory.createVehicle() — the concrete class stays hidden.
Same structure in Java: interfaces + concrete factories (diagram labels may say C++; logic is identical)
Client depends on CarFactory, Car, and CarSpecification — concrete factories wire each family
Modern vs Victorian — each theme needs a matching chair and table. The client uses FurnitureFactory, Chair, and Table only; ModernFurnitureFactory returns ModernChair + ModernTable, and similarly for Victorian.
Same structure: abstract factory + two product interfaces + concrete families
this so calls chain: builder.a().b().build()Participants: Builder (steps + build()), ConcreteBuilder (often fluent inner class), Product (complex result), Director (optional — orchestrates step order).
Classic Builder structure (Director optional for fluent APIs)
Director encodes recipes; fluent Builder sets method, headers, body, timeout; build() yields HttpRequest
Chaining returns this; build() constructs the product — often immutable after that
build() — validate, construct product (private constructor + builder state)clone() (or copy operation)
Prototype interface, concrete Shape, client Main
new from outsidegetInstance() creates (once) or returns existing
No direct construction — access through the static gateway
Multiple references, one heap object
Classic lazy if (obj == null) — not safe under concurrency
volatile)