Introduction to Creational Patterns

Master the art of creating objects - build flexible, maintainable systems!

By Vishnu Darshan Sanku · Updated September 25, 2026

What Are Creational Patterns?

Creational patterns are design patterns that deal with object creation mechanisms. They help you create objects in a way that’s flexible, maintainable, and decoupled from the rest of your code.

Think of creational patterns as smart ways to build things - instead of directly constructing objects everywhere, they provide structured approaches to object creation.

Understanding Creational Patterns

Creational patterns focus on how objects are instantiated. They abstract the instantiation process, making your code more flexible and easier to maintain.

Key characteristics:

Decouple object creation from object usage
Provide flexibility in what gets created
Centralize creation logic for better control
Support extensibility - Easy to add new types
Hide complexity - Client code doesn’t need to know creation details

Visual Overview

Creational pattern comparison: three clients each calling new ConcreteClass directly versus one client creating objects through a central Factory

Interaction Flow Comparison

Here’s how object creation works with and without creational patterns:

Sequence comparison: clients instantiating ConcreteClass directly versus requesting instances through Factory create, centralizing creation logic

Why Do We Need Creational Patterns?

Object creation seems simple - just use new ClassName(), right? But in real-world applications, object creation can become complex and problematic.

The Problem with Direct Object Creation

When you create objects directly throughout your code, you face several challenges:

1. Tight Coupling

Your code becomes tightly coupled to specific classes
Changing a class name or constructor requires updating code everywhere

2. Complex Initialization

Some objects need complex setup (multiple parameters, validation, configuration)
This logic gets scattered across your codebase

3. Runtime Type Determination

Sometimes you don’t know which class to instantiate until runtime
Direct creation doesn’t handle this flexibility

4. Violation of SOLID Principles

Hard to follow Open/Closed Principle (open for extension, closed for modification)
Difficult to apply Dependency Inversion Principle

What’s the Use of Creational Patterns?

Creational patterns solve common object creation problems:

1. Flexibility in Object Creation

Creational patterns let you decide what type of object to create at runtime, not compile time.

Example:

💡 Tip: Click dropdown to switch between languages

1
# Without creational pattern - hardcoded
2
payment = StripePayment(api_key)
3

4
# With creational pattern - flexible
5
payment = PaymentFactory.create(gateway_type, config)

1
// Without creational pattern - hardcoded
2
Payment payment = new StripePayment(apiKey);
3

4
// With creational pattern - flexible
5
Payment payment = PaymentFactory.create(gatewayType, config);

1
// Without creational pattern - hardcoded
2
const payment = new StripePayment(apiKey);
3

4
// With creational pattern - flexible
5
const payment = PaymentFactory.create(gatewayType, config);

1
// Without creational pattern - hardcoded
2
Payment* payment = new StripePayment(apiKey);
3

4
// With creational pattern - flexible
5
Payment* payment = PaymentFactory::create(gatewayType, config);

1
// Without creational pattern - hardcoded
2
var payment = new StripePayment(apiKey);
3

4
// With creational pattern - flexible
5
var payment = PaymentFactory.Create(gatewayType, config);

1
// Without creational pattern - hardcoded
2
payment := NewStripePayment(apiKey)
3

4
// With creational pattern - flexible
5
payment = PaymentFactory.Create(gatewayType, config)

1
// 1. Flexibility in Object Creation
2
struct App;
3
impl App {
4
    fn create_everything_directly(&self) {
5
        println!("new logger");
6
        println!("new service");
7
    }
8
}

2. Centralized Creation Logic

All object creation logic lives in one place, making it easier to:

Maintain - Update creation logic in one spot
Test - Mock factories easily
Debug - Trace creation issues quickly

3. Decoupling

Your code doesn’t depend on concrete classes - it depends on abstractions (interfaces or base classes).

Example:

💡 Tip: Click dropdown to switch between languages

1
# Tightly coupled - depends on concrete class
2
def process_payment():
3
    stripe = StripePayment(api_key)  # Hard-coded!
4
    stripe.process()
5

6
# Decoupled - depends on abstraction
7
def process_payment(factory):
8
    payment = factory.create()  # Works with any payment type!
9
    payment.process()

1
// Tightly coupled - depends on concrete class
2
void processPayment() {
3
    var stripe = new StripePayment(apiKey);  // Hard-coded!
4
    stripe.process();
5
}
6

7
// Decoupled - depends on abstraction
8
void processPayment(PaymentFactory factory) {
9
    var payment = factory.create();  // Works with any payment type!
10
    payment.process();
11
}

1
// Tightly coupled - depends on concrete class
2
function processPayment() {
3
    const stripe = new StripePayment(apiKey);  // Hard-coded!
4
    stripe.process();
5
}
6

7
// Decoupled - depends on abstraction
8
function processPayment(factory: PaymentFactory) {
9
    const payment = factory.create();  // Works with any payment type!
10
    payment.process();
11
}

1
// Tightly coupled - depends on concrete class
2
void processPayment() {
3
    auto* stripe = new StripePayment(apiKey);  // Hard-coded!
4
    stripe->process();
5
}
6

7
// Decoupled - depends on abstraction
8
void processPayment(PaymentFactory* factory) {
9
    auto* payment = factory->create();  // Works with any payment type!
10
    payment->process();
11
}

1
// Tightly coupled - depends on concrete class
2
void ProcessPayment() {
3
    var stripe = new StripePayment(apiKey);  // Hard-coded!
4
    stripe.Process();
5
}
6

7
// Decoupled - depends on abstraction
8
void ProcessPayment(IPaymentFactory factory) {
9
    var payment = factory.Create();  // Works with any payment type!
10
    payment.Process();
11
}

1
// Tightly coupled — depends on concrete type
2
func ProcessPayment(apiKey string) {
3
  stripe := NewStripePayment(apiKey) // Hard-coded!
4
  stripe.Process()
5
}
6

7
// Decoupled — depends on abstraction
8
func ProcessPaymentWithFactory(factory IPaymentFactory) {
9
  payment := factory.Create() // Works with any payment type!
10
  payment.Process()
11
}

1
// 3. Decoupling
2
trait Service {
3
    fn run(&self);
4
}
5
struct DefaultService;
6
impl Service for DefaultService {
7
    fn run(&self) {
8
        println!("service running");
9
    }
10
}
11
struct ServiceFactory;
12
impl ServiceFactory {
13
    fn create() -> Box<dyn Service> {
14
        Box::new(DefaultService)
15
    }
16
}

4. Complex Object Construction

Some objects need step-by-step construction with validation and configuration. Creational patterns handle this elegantly.

Example:

💡 Tip: Click dropdown to switch between languages

1
# Complex construction without pattern - messy!
2
user = User()
3
user.set_name("John")
4
user.set_email("[email protected]")
5
user.validate_email()
6
user.set_role("admin")
7
user.set_permissions(["read", "write"])
8
# ... many more steps
9

10
# With Builder pattern - clean!
11
user = UserBuilder() \
12
    .with_name("John") \
13
    .with_email("[email protected]") \
14
    .with_role("admin") \
15
    .build()

1
// Complex construction without pattern - messy!
2
User user = new User();
3
user.setName("John");
4
user.setEmail("[email protected]");
5
user.validateEmail();
6
user.setRole("admin");
7
user.setPermissions(List.of("read", "write"));
8
// ... many more steps
9

10
// With Builder pattern - clean!
11
User user = new UserBuilder()
12
    .withName("John")
13
    .withEmail("[email protected]")
14
    .withRole("admin")
15
    .build();

1
// Complex construction without pattern - messy!
2
const user = new User();
3
user.setName("John");
4
user.setEmail("[email protected]");
5
user.validateEmail();
6
user.setRole("admin");
7
user.setPermissions(["read", "write"]);
8
// ... many more steps
9

10
// With Builder pattern - clean!
11
const user = new UserBuilder()
12
    .withName("John")
13
    .withEmail("[email protected]")
14
    .withRole("admin")
15
    .build();

1
// Complex construction without pattern - messy!
2
User user;
3
user.setName("John");
4
user.setEmail("[email protected]");
5
user.validateEmail();
6
user.setRole("admin");
7
user.setPermissions({"read", "write"});
8
// ... many more steps
9

10
// With Builder pattern - clean!
11
User user = UserBuilder()
12
    .withName("John")
13
    .withEmail("[email protected]")
14
    .withRole("admin")
15
    .build();

1
// Complex construction without pattern - messy!
2
var user = new User();
3
user.SetName("John");
4
user.SetEmail("[email protected]");
5
user.ValidateEmail();
6
user.SetRole("admin");
7
user.SetPermissions(new[] { "read", "write" });
8
// ... many more steps
9

10
// With Builder pattern - clean!
11
var user = new UserBuilder()
12
    .WithName("John")
13
    .WithEmail("[email protected]")
14
    .WithRole("admin")
15
    .Build();

1
// Complex construction without pattern — messy!
2
user := NewUser()
3
user.SetName("John")
4
user.SetEmail("[email protected]")
5
user.ValidateEmail()
6
user.SetRole("admin")
7
user.SetPermissions([]string{"read", "write"})
8
// ... many more steps
9

10
// With Builder pattern — clean!
11
user := NewUserBuilder().
12
  WithName("John").
13
  WithEmail("[email protected]").
14
  WithRole("admin").
15
  Build()

1
// 4. Complex Object Construction
2
struct App;
3
impl App {
4
    fn create_everything_directly(&self) {
5
        println!("new logger");
6
        println!("new service");
7
    }
8
}

5. Resource Management

Some objects should only exist once (like database connections). Creational patterns ensure proper resource management.

What Happens If We Don’t Use Creational Patterns?

Without creational patterns, you’ll face several problems:

1. Scattered Creation Logic

Object creation code spreads throughout your codebase, making it hard to:

Find where objects are created
Update creation logic
Understand the system

Example:

💡 Tip: Click dropdown to switch between languages

1
# ❌ Creation logic scattered everywhere
2
def checkout():
3
    payment = StripePayment(stripe_key)  # Created here
4
    # ... checkout logic
5

6
def refund():
7
    payment = StripePayment(stripe_key)  # Created again here
8
    # ... refund logic
9

10
def subscription():
11
    payment = StripePayment(stripe_key)  # Created again!
12
    # ... subscription logic

1
// ❌ Creation logic scattered everywhere
2
void checkout() {
3
    var payment = new StripePayment(stripeKey);  // Created here
4
    // ... checkout logic
5
}
6
void refund() {
7
    var payment = new StripePayment(stripeKey);  // Created again here
8
    // ... refund logic
9
}
10
void subscription() {
11
    var payment = new StripePayment(stripeKey);  // Created again!
12
    // ... subscription logic
13
}

1
// ❌ Creation logic scattered everywhere
2
function checkout() {
3
    const payment = new StripePayment(stripeKey);  // Created here
4
    // ... checkout logic
5
}
6
function refund() {
7
    const payment = new StripePayment(stripeKey);  // Created again here
8
    // ... refund logic
9
}
10
function subscription() {
11
    const payment = new StripePayment(stripeKey);  // Created again!
12
    // ... subscription logic
13
}

1
// ❌ Creation logic scattered everywhere
2
void checkout() {
3
    auto* payment = new StripePayment(stripeKey);  // Created here
4
    // ... checkout logic
5
}
6
void refund() {
7
    auto* payment = new StripePayment(stripeKey);  // Created again here
8
    // ... refund logic
9
}
10
void subscription() {
11
    auto* payment = new StripePayment(stripeKey);  // Created again!
12
    // ... subscription logic
13
}

1
// ❌ Creation logic scattered everywhere
2
void Checkout() {
3
    var payment = new StripePayment(stripeKey);  // Created here
4
    // ... checkout logic
5
}
6
void Refund() {
7
    var payment = new StripePayment(stripeKey);  // Created again here
8
    // ... refund logic
9
}
10
void Subscription() {
11
    var payment = new StripePayment(stripeKey);  // Created again!
12
    // ... subscription logic
13
}

1
// ❌ Creation logic scattered everywhere
2
func Checkout() {
3
  payment := NewStripePayment(stripeKey) // Created here
4
  // ... checkout logic
5
}
6
func Refund() {
7
  payment := NewStripePayment(stripeKey) // Created again here
8
  // ... refund logic
9
}
10
func Subscription() {
11
  payment := NewStripePayment(stripeKey) // Created again!
12
  // ... subscription logic
13
}

1
// 1. Scattered Creation Logic
2
trait Service {
3
    fn run(&self);
4
}
5
struct DefaultService;
6
impl Service for DefaultService {
7
    fn run(&self) {
8
        println!("service running");
9
    }
10
}
11
struct ServiceFactory;
12
impl ServiceFactory {
13
    fn create() -> Box<dyn Service> {
14
        Box::new(DefaultService)
15
    }
16
}

Problems:

If Stripe API changes, you need to update 3+ places
Hard to switch to a different payment provider
Can’t easily test with mock payments

2. Tight Coupling

Your code becomes tightly coupled to specific classes, making it hard to:

Switch implementations
Add new types
Test with mocks

Example:

💡 Tip: Click dropdown to switch between languages

1
# ❌ Tightly coupled to StripePayment
2
class OrderService:
3
    def process_order(self):
4
        payment = StripePayment(api_key)  # Hard-coded!
5
        payment.process()
6

7
# If you want to use PayPal, you need to modify this class!

1
// ❌ Tightly coupled to StripePayment
2
class OrderService {
3
    void processOrder() {
4
        var payment = new StripePayment(apiKey);  // Hard-coded!
5
        payment.process();
6
    }
7
}
8
// If you want to use PayPal, you need to modify this class!

1
// ❌ Tightly coupled to StripePayment
2
class OrderService {
3
    processOrder() {
4
        const payment = new StripePayment(apiKey);  // Hard-coded!
5
        payment.process();
6
    }
7
}
8
// If you want to use PayPal, you need to modify this class!

1
// ❌ Tightly coupled to StripePayment
2
class OrderService {
3
    void processOrder() {
4
        auto* payment = new StripePayment(apiKey);  // Hard-coded!
5
        payment->process();
6
    }
7
};
8
// If you want to use PayPal, you need to modify this class!

1
// ❌ Tightly coupled to StripePayment
2
class OrderService {
3
    void ProcessOrder() {
4
        var payment = new StripePayment(apiKey);  // Hard-coded!
5
        payment.Process();
6
    }
7
}
8
// If you want to use PayPal, you need to modify this class!

1
// ❌ Tightly coupled to StripePayment
2
type OrderService struct{}
3

4
func (*OrderService) ProcessOrder(apiKey string) {
5
  payment := NewStripePayment(apiKey) // Hard-coded!
6
  payment.Process()
7
}
8
// If you want to use PayPal, you need to modify this type!

1
// 2. Tight Coupling
2
trait Service {
3
    fn run(&self);
4
}
5
struct DefaultService;
6
impl Service for DefaultService {
7
    fn run(&self) {
8
        println!("service running");
9
    }
10
}
11
struct ServiceFactory;
12
impl ServiceFactory {
13
    fn create() -> Box<dyn Service> {
14
        Box::new(DefaultService)
15
    }
16
}

3. Violation of SOLID Principles

Without creational patterns, you often violate:

Open/Closed Principle - Need to modify code to add new types
Dependency Inversion - Depend on concrete classes, not abstractions
Single Responsibility - Classes handle both business logic and object creation

4. Complex Initialization Scattered

When objects need complex setup, that logic gets duplicated everywhere:

Example:

💡 Tip: Click dropdown to switch between languages

1
# ❌ Complex initialization duplicated
2
def create_user_v1():
3
    user = User()
4
    user.set_name(name)
5
    user.set_email(email)
6
    user.validate()
7
    user.set_role("user")
8
    user.initialize_permissions()
9
    return user
10

11
def create_user_v2():
12
    user = User()
13
    user.set_name(name)  # Duplicated!
14
    user.set_email(email)  # Duplicated!
15
    user.validate()  # Duplicated!
16
    # ... same logic repeated

1
// ❌ Complex initialization duplicated
2
User createUserV1() {
3
    User user = new User();
4
    user.setName(name);
5
    user.setEmail(email);
6
    user.validate();
7
    user.setRole("user");
8
    user.initializePermissions();
9
    return user;
10
}
11
User createUserV2() {
12
    User user = new User();
13
    user.setName(name);   // Duplicated!
14
    user.setEmail(email); // Duplicated!
15
    user.validate();      // Duplicated!
16
    // ... same logic repeated
17
    return user;
18
}

1
// ❌ Complex initialization duplicated
2
function createUserV1() {
3
    const user = new User();
4
    user.setName(name);
5
    user.setEmail(email);
6
    user.validate();
7
    user.setRole("user");
8
    user.initializePermissions();
9
    return user;
10
}
11
function createUserV2() {
12
    const user = new User();
13
    user.setName(name);   // Duplicated!
14
    user.setEmail(email); // Duplicated!
15
    user.validate();      // Duplicated!
16
    // ... same logic repeated
17
    return user;
18
}

1
// ❌ Complex initialization duplicated
2
User createUserV1() {
3
    User user;
4
    user.setName(name);
5
    user.setEmail(email);
6
    user.validate();
7
    user.setRole("user");
8
    user.initializePermissions();
9
    return user;
10
}
11
User createUserV2() {
12
    User user;
13
    user.setName(name);   // Duplicated!
14
    user.setEmail(email); // Duplicated!
15
    user.validate();      // Duplicated!
16
    // ... same logic repeated
17
    return user;
18
}

1
// ❌ Complex initialization duplicated
2
User CreateUserV1() {
3
    var user = new User();
4
    user.SetName(name);
5
    user.SetEmail(email);
6
    user.Validate();
7
    user.SetRole("user");
8
    user.InitializePermissions();
9
    return user;
10
}
11
User CreateUserV2() {
12
    var user = new User();
13
    user.SetName(name);   // Duplicated!
14
    user.SetEmail(email); // Duplicated!
15
    user.Validate();      // Duplicated!
16
    // ... same logic repeated
17
    return user;
18
}

1
// ❌ Complex initialization duplicated
2
func CreateUserV1(name, email string) *User {
3
  user := NewUser()
4
  user.SetName(name)
5
  user.SetEmail(email)
6
  user.Validate()
7
  user.SetRole("user")
8
  user.InitializePermissions()
9
  return user
10
}
11

12
func CreateUserV2(name, email string) *User {
13
  user := NewUser()
14
  user.SetName(name)   // Duplicated!
15
  user.SetEmail(email) // Duplicated!
16
  user.Validate()      // Duplicated!
17
  // ... same logic repeated
18
  return user
19
}

1
// 4. Complex Initialization Scattered
2
trait Service {
3
    fn run(&self);
4
}
5
struct DefaultService;
6
impl Service for DefaultService {
7
    fn run(&self) {
8
        println!("service running");
9
    }
10
}
11
struct ServiceFactory;
12
impl ServiceFactory {
13
    fn create() -> Box<dyn Service> {
14
        Box::new(DefaultService)
15
    }
16
}

5. Hard to Test

Without creational patterns, testing becomes difficult:

Can’t easily swap real objects with test doubles
Need to set up complex dependencies everywhere
Hard to isolate units for testing

Simple Example: The Problem We’re Solving

Let’s see a simple example that shows why creational patterns matter:

The Scenario: Building a Notification System

You’re building a notification system that can send messages via Email, SMS, or Push notifications.

Visual Comparison

Interaction Flow: Notification System

Here’s how the notification system works with and without creational patterns:

Without Creational Pattern

💡 Tip: Click dropdown to switch between languages

1
# ❌ Without Creational Pattern - Problems everywhere!
2

3
class EmailNotification:
4
    def send(self, message):
5
        print(f"📧 Email sent: {message}")
6

7
class SMSNotification:
8
    def send(self, message):
9
        print(f"📱 SMS sent: {message}")
10

11
# Problem: Creation logic scattered everywhere
12
def checkout():
13
    notification = EmailNotification()  # Created here
14
    notification.send("Order confirmed")
15

16
def refund():
17
    notification = EmailNotification()  # Created again here
18
    notification.send("Refund processed")
19

20
def subscribe():
21
    notification = EmailNotification()  # Created again!
22
    notification.send("Subscription active")
23

24
# Problems:
25
# - Creation logic duplicated 3 times
26
# - Hard to switch to SMS (need to change 3 places)
27
# - Tight coupling to EmailNotification

1
// ❌ Without Creational Pattern - Problems everywhere!
2

3
public class EmailNotification {
4
    public void send(String message) {
5
        System.out.println("📧 Email sent: " + message);
6
    }
7
}
8

9
public class SMSNotification {
10
    public void send(String message) {
11
        System.out.println("📱 SMS sent: " + message);
12
    }
13
}
14

15
// Problem: Creation logic scattered everywhere
16
public class OrderService {
17
    public void checkout() {
18
        EmailNotification notification = new EmailNotification();  // Created here
19
        notification.send("Order confirmed");
20
    }
21

22
    public void refund() {
23
        EmailNotification notification = new EmailNotification();  // Created again here
24
        notification.send("Refund processed");
25
    }
26

27
    public void subscribe() {
28
        EmailNotification notification = new EmailNotification();  // Created again!
29
        notification.send("Subscription active");
30
    }
31
}
32

33
// Problems:
34
// - Creation logic duplicated 3 times
35
// - Hard to switch to SMS (need to change 3 places)
36
// - Tight coupling to EmailNotification
37
}

1
// ❌ Without Creational Pattern - Problems everywhere!
2

3
class EmailNotification {
4
    send(message: string): void {
5
        console.log(`📧 Email sent: ${message}`);
6
    }
7
}
8

9
class SMSNotification {
10
    send(message: string): void {
11
        console.log(`📱 SMS sent: ${message}`);
12
    }
13
}
14

15
// Problem: Creation logic scattered everywhere
16
function checkout(): void {
17
    const notification = new EmailNotification();  // Created here
18
    notification.send("Order confirmed");
19
}
20

21
function refund(): void {
22
    const notification = new EmailNotification();  // Created again here
23
    notification.send("Refund processed");
24
}
25

26
function subscribe(): void {
27
    const notification = new EmailNotification();  // Created again!
28
    notification.send("Subscription active");
29
}
30

31
// Problems:
32
// - Creation logic duplicated 3 times
33
// - Hard to switch to SMS (need to change 3 places)
34
// - Tight coupling to EmailNotification

1
// ❌ Without Creational Pattern - Problems everywhere!
2

3
#include <iostream>
4
#include <string>
5

6
class EmailNotification {
7
public:
8
    void send(const std::string& message) {
9
        std::cout << "📧 Email sent: " << message << std::endl;
10
    }
11
};
12

13
class SMSNotification {
14
public:
15
    void send(const std::string& message) {
16
        std::cout << "📱 SMS sent: " << message << std::endl;
17
    }
18
};
19

20
// Problem: Creation logic scattered everywhere
21
void checkout() {
22
    EmailNotification notification;  // Created here
23
    notification.send("Order confirmed");
24
}
25

26
void refund() {
27
    EmailNotification notification;  // Created again here
28
    notification.send("Refund processed");
29
}
30

31
void subscribe() {
32
    EmailNotification notification;  // Created again!
33
    notification.send("Subscription active");
34
}
35

36
// Problems:
37
// - Creation logic duplicated 3 times
38
// - Hard to switch to SMS (need to change 3 places)
39
// - Tight coupling to EmailNotification

1
// ❌ Without Creational Pattern - Problems everywhere!
2

3
using System;
4

5
public class EmailNotification
6
{
7
    public void Send(string message)
8
    {
9
        Console.WriteLine($"📧 Email sent: {message}");
10
    }
11
}
12

13
public class SMSNotification
14
{
15
    public void Send(string message)
16
    {
17
        Console.WriteLine($"📱 SMS sent: {message}");
18
    }
19
}
20

21
// Problem: Creation logic scattered everywhere
22
public class OrderService
23
{
24
    public void Checkout()
25
    {
26
        EmailNotification notification = new EmailNotification();  // Created here
27
        notification.Send("Order confirmed");
28
    }
29

30
    public void Refund()
31
    {
32
        EmailNotification notification = new EmailNotification();  // Created again here
33
        notification.Send("Refund processed");
34
    }
35

36
    public void Subscribe()
37
    {
38
        EmailNotification notification = new EmailNotification();  // Created again!
39
        notification.Send("Subscription active");
40
    }
41
}
42

43
// Problems:
44
// - Creation logic duplicated 3 times
45
// - Hard to switch to SMS (need to change 3 places)
46
// - Tight coupling to EmailNotification

1
// ❌ Without Creational Pattern - Problems everywhere!
2

3
package main
4

5
import "fmt"
6

7
type EmailNotification struct{}
8

9
func (EmailNotification) Send(message string) {
10
  fmt.Printf("📧 Email sent: %s\n", message)
11
}
12

13
type SMSNotification struct{}
14

15
func (SMSNotification) Send(message string) {
16
  fmt.Printf("📱 SMS sent: %s\n", message)
17
}
18

19
// Problem: Creation logic scattered everywhere
20
type OrderService struct{}
21

22
func (*OrderService) Checkout() {
23
  notification := EmailNotification{} // Created here
24
  notification.Send("Order confirmed")
25
}
26

27
func (*OrderService) Refund() {
28
  notification := EmailNotification{} // Created again here
29
  notification.Send("Refund processed")
30
}
31

32
func (*OrderService) Subscribe() {
33
  notification := EmailNotification{} // Created again!
34
  notification.Send("Subscription active")
35
}
36

37
// Problems:
38
// - Creation logic duplicated 3 times
39
// - Hard to switch to SMS (need to change 3 places)
40
// - Tight coupling to EmailNotification

1
// Without Creational Pattern
2
struct App;
3
impl App {
4
    fn create_everything_directly(&self) {
5
        println!("new logger");
6
        println!("new service");
7
    }
8
}

Problems:

❌ Creation logic scattered across multiple functions
❌ Hard to add new notification types (need to modify multiple places)
❌ Tight coupling to specific notification classes
❌ Can’t easily switch notification methods
❌ Duplicated initialization code

With Creational Pattern (Factory)

💡 Tip: Click dropdown to switch between languages

1
# ✅ With Creational Pattern - Clean and flexible!
2

3
from abc import ABC, abstractmethod
4

5
# Step 1: Define the interface
6
class Notification(ABC):
7
    @abstractmethod
8
    def send(self, message: str) -> None:
9
        pass
10

11
# Step 2: Create concrete implementations
12
class EmailNotification(Notification):
13
    def send(self, message: str) -> None:
14
        print(f"📧 Email sent: {message}")
15

16
class SMSNotification(Notification):
17
    def send(self, message: str) -> None:
18
        print(f"📱 SMS sent: {message}")
19

20
# Step 3: Create the Factory
21
class NotificationFactory:
22
    @staticmethod
23
    def create(notification_type: str) -> Notification:
24
        """Factory method - centralized creation logic"""
25
        if notification_type == "email":
26
            return EmailNotification()
27
        elif notification_type == "sms":
28
            return SMSNotification()
29
        else:
30
            raise ValueError(f"Unknown type: {notification_type}")
31

32
# Step 4: Use the factory - clean and simple!
33
def checkout():
34
    notification = NotificationFactory.create("email")  # Factory handles creation
35
    notification.send("Order confirmed")
36

37
def refund():
38
    notification = NotificationFactory.create("email")  # Same factory method
39
    notification.send("Refund processed")
40

41
# Benefits:
42
# - Creation logic in one place
43
# - Easy to switch to SMS (change "email" to "sms")
44
# - Decoupled from specific classes

1
// ✅ With Creational Pattern - Clean and flexible!
2

3
// Step 1: Define the interface
4
public interface Notification {
5
    void send(String message);
6
}
7

8
// Step 2: Create concrete implementations
9
public class EmailNotification implements Notification {
10
    @Override
11
    public void send(String message) {
12
        System.out.println("📧 Email sent: " + message);
13
    }
14
}
15

16
public class SMSNotification implements Notification {
17
    @Override
18
    public void send(String message) {
19
        System.out.println("📱 SMS sent: " + message);
20
    }
21
}
22

23
// Step 3: Create the Factory
24
public class NotificationFactory {
25
    public static Notification create(String notificationType) {
26
        // Factory method - centralized creation logic
27
        if ("email".equals(notificationType)) {
28
            return new EmailNotification();
29
        } else if ("sms".equals(notificationType)) {
30
            return new SMSNotification();
31
        } else {
32
            throw new IllegalArgumentException("Unknown type: " + notificationType);
33
        }
34
    }
35
}
36

37
// Step 4: Use the factory - clean and simple!
38
public class OrderService {
39
    public void checkout() {
40
        Notification notification = NotificationFactory.create("email");  // Factory handles creation
41
        notification.send("Order confirmed");
42
    }
43

44
    public void refund() {
45
        Notification notification = NotificationFactory.create("email");  // Same factory method
46
        notification.send("Refund processed");
47
    }
48
}
49

50
// Benefits:
51
// - Creation logic in one place
52
// - Easy to switch to SMS (change "email" to "sms")
53
// - Decoupled from specific classes
54
}

1
// ✅ With Creational Pattern - Clean and flexible!
2

3
// Step 1: Define the interface
4
interface Notification {
5
    send(message: string): void;
6
}
7

8
// Step 2: Create concrete implementations
9
class EmailNotification implements Notification {
10
    send(message: string): void {
11
        console.log(`📧 Email sent: ${message}`);
12
    }
13
}
14

15
class SMSNotification implements Notification {
16
    send(message: string): void {
17
        console.log(`📱 SMS sent: ${message}`);
18
    }
19
}
20

21
// Step 3: Create the Factory
22
class NotificationFactory {
23
    static create(notificationType: string): Notification {
24
        /** Factory method - centralized creation logic */
25
        if (notificationType === "email") {
26
            return new EmailNotification();
27
        } else if (notificationType === "sms") {
28
            return new SMSNotification();
29
        } else {
30
            throw new Error(`Unknown type: ${notificationType}`);
31
        }
32
    }
33
}
34

35
// Step 4: Use the factory - clean and simple!
36
function checkout(): void {
37
    const notification = NotificationFactory.create("email");  // Factory handles creation
38
    notification.send("Order confirmed");
39
}
40

41
function refund(): void {
42
    const notification = NotificationFactory.create("email");  // Same factory method
43
    notification.send("Refund processed");
44
}
45

46
// Benefits:
47
// - Creation logic in one place
48
// - Easy to switch to SMS (change "email" to "sms")
49
// - Decoupled from specific classes

1
// ✅ With Creational Pattern - Clean and flexible!
2

3
#include <iostream>
4
#include <string>
5
#include <memory>
6
#include <stdexcept>
7

8
// Step 1: Define the interface
9
class Notification {
10
public:
11
    virtual ~Notification() = default;
12
    virtual void send(const std::string& message) = 0;
13
};
14

15
// Step 2: Create concrete implementations
16
class EmailNotification : public Notification {
17
public:
18
    void send(const std::string& message) override {
19
        std::cout << "📧 Email sent: " << message << std::endl;
20
    }
21
};
22

23
class SMSNotification : public Notification {
24
public:
25
    void send(const std::string& message) override {
26
        std::cout << "📱 SMS sent: " << message << std::endl;
27
    }
28
};
29

30
// Step 3: Create the Factory
31
class NotificationFactory {
32
public:
33
    // Factory method - centralized creation logic
34
    static std::unique_ptr<Notification> create(const std::string& notificationType) {
35
        if (notificationType == "email") {
36
            return std::make_unique<EmailNotification>();
37
        } else if (notificationType == "sms") {
38
            return std::make_unique<SMSNotification>();
39
        } else {
40
            throw std::invalid_argument("Unknown type: " + notificationType);
41
        }
42
    }
43
};
44

45
// Step 4: Use the factory - clean and simple!
46
void checkout() {
47
    auto notification = NotificationFactory::create("email");  // Factory handles creation
48
    notification->send("Order confirmed");
49
}
50

51
void refund() {
52
    auto notification = NotificationFactory::create("email");  // Same factory method
53
    notification->send("Refund processed");
54
}
55

56
// Benefits:
57
// - Creation logic in one place
58
// - Easy to switch to SMS (change "email" to "sms")
59
// - Decoupled from specific classes

1
// ✅ With Creational Pattern - Clean and flexible!
2

3
using System;
4

5
// Step 1: Define the interface
6
public interface INotification
7
{
8
    void Send(string message);
9
}
10

11
// Step 2: Create concrete implementations
12
public class EmailNotification : INotification
13
{
14
    public void Send(string message)
15
    {
16
        Console.WriteLine($"📧 Email sent: {message}");
17
    }
18
}
19

20
public class SMSNotification : INotification
21
{
22
    public void Send(string message)
23
    {
24
        Console.WriteLine($"📱 SMS sent: {message}");
25
    }
26
}
27

28
// Step 3: Create the Factory
29
public class NotificationFactory
30
{
31
    public static INotification Create(string notificationType)
32
    {
33
        // Factory method - centralized creation logic
34
        if (notificationType == "email")
35
        {
36
            return new EmailNotification();
37
        }
38
        else if (notificationType == "sms")
39
        {
40
            return new SMSNotification();
41
        }
42
        else
43
        {
44
            throw new ArgumentException($"Unknown type: {notificationType}");
45
        }
46
    }
47
}
48

49
// Step 4: Use the factory - clean and simple!
50
public class OrderService
51
{
52
    public void Checkout()
53
    {
54
        INotification notification = NotificationFactory.Create("email");  // Factory handles creation
55
        notification.Send("Order confirmed");
56
    }
57

58
    public void Refund()
59
    {
60
        INotification notification = NotificationFactory.Create("email");  // Same factory method
61
        notification.Send("Refund processed");
62
    }
63
}
64

65
// Benefits:
66
// - Creation logic in one place
67
// - Easy to switch to SMS (change "email" to "sms")
68
// - Decoupled from specific classes

1
// ✅ With Creational Pattern - Clean and flexible!
2

3
package main
4

5
import (
6
  "fmt"
7
)
8

9
// Step 1: Define the interface
10
type Notification interface {
11
  Send(message string)
12
}
13

14
// Step 2: Create concrete implementations
15
type EmailNotification struct{}
16

17
func (EmailNotification) Send(message string) {
18
  fmt.Printf("📧 Email sent: %s\n", message)
19
}
20

21
type SMSNotification struct{}
22

23
func (SMSNotification) Send(message string) {
24
  fmt.Printf("📱 SMS sent: %s\n", message)
25
}
26

27
// Step 3: Create the Factory
28
type NotificationFactory struct{}
29

30
func (NotificationFactory) Create(notificationType string) Notification {
31
  // Factory method — centralized creation logic
32
  switch notificationType {
33
  case "email":
34
    return EmailNotification{}
35
  case "sms":
36
    return SMSNotification{}
37
  default:
38
    panic(fmt.Sprintf("Unknown type: %s", notificationType))
39
  }
40
}
41

42
// Step 4: Use the factory - clean and simple!
43
type OrderService struct{}
44

45
func (*OrderService) Checkout() {
46
  notification := NotificationFactory{}.Create("email") // Factory handles creation
47
  notification.Send("Order confirmed")
48
}
49

50
func (*OrderService) Refund() {
51
  notification := NotificationFactory{}.Create("email") // Same factory method
52
  notification.Send("Refund processed")
53
}
54

55
// Benefits:
56
// - Creation logic in one place
57
// - Easy to switch to SMS (change "email" to "sms")
58
// - Decoupled from specific types

1
// With Creational Pattern Factory
2
trait Service {
3
    fn run(&self);
4
}
5
struct DefaultService;
6
impl Service for DefaultService {
7
    fn run(&self) {
8
        println!("service running");
9
    }
10
}
11
struct ServiceFactory;
12
impl ServiceFactory {
13
    fn create() -> Box<dyn Service> {
14
        Box::new(DefaultService)
15
    }
16
}

Benefits:

✅ Centralized creation - All creation logic in one place
✅ Easy to extend - Add new types without modifying existing code
✅ Decoupled - Code doesn’t depend on specific notification classes
✅ Flexible - Can switch notification methods easily
✅ Testable - Easy to mock the factory

Class Structure

Types of Creational Patterns

Creational patterns come in different flavors, each solving specific creation problems:

Overview of the five creational patterns: Factory, Builder, Singleton, Prototype and Abstract Factory, each with its purpose

1. Factory Pattern

Problem: Need to create objects without specifying exact classes
Solution: Use a factory method that creates objects based on input
When to use: When object creation depends on runtime conditions

2. Builder Pattern

Problem: Complex objects with many optional parameters
Solution: Build objects step-by-step with a fluent interface
When to use: When objects need complex construction with validation

Key Takeaways

What We Learned

Creational patterns focus on how objects are created
Why we need them: Direct creation leads to tight coupling, scattered logic, and hard-to-maintain code
What they solve: Flexibility, decoupling, centralized logic, complex construction
What happens without them: Scattered code, tight coupling, SOLID violations, hard testing

Next Steps

Now that you understand creational patterns, explore specific patterns:

Factory Pattern - Create objects without knowing exact classes
Abstract Factory Pattern - Create families of related objects
Builder Pattern - Build complex objects step by step
Prototype Pattern - Clone existing objects
Singleton Pattern - Ensure only one instance exists

Remember: Creational patterns are about making object creation flexible, maintainable, and decoupled. Use them wisely! 🏭

Share feedback or report an issue

Introduction to Creational Patterns

What Are Creational Patterns?

Understanding Creational Patterns

Visual Overview

Interaction Flow Comparison

Why Do We Need Creational Patterns?

The Problem with Direct Object Creation

What’s the Use of Creational Patterns?

1. Flexibility in Object Creation

2. Centralized Creation Logic

3. Decoupling

4. Complex Object Construction

5. Resource Management

What Happens If We Don’t Use Creational Patterns?

1. Scattered Creation Logic

2. Tight Coupling

3. Violation of SOLID Principles

4. Complex Initialization Scattered

5. Hard to Test

Simple Example: The Problem We’re Solving

The Scenario: Building a Notification System

Visual Comparison

Interaction Flow: Notification System

Without Creational Pattern

With Creational Pattern (Factory)

Class Structure

Types of Creational Patterns

1. Factory Pattern

2. Builder Pattern

3. Singleton Pattern

4. Prototype Pattern

5. Abstract Factory Pattern

Key Takeaways

What We Learned

Next Steps