Creational patterns solve the problem of creating objects in a flexible and reusable way. When I built my Agentic LLM Search project, I needed to instantiate different LLM providers (Azure OpenAI, local TinyLlama) without hardcoding dependencies. Creational patterns made this possible.
This guide covers four essential creational patterns I use regularly in my TypeScript projects:
Factory Pattern - Creating objects without specifying exact classes
Singleton Pattern - Ensuring only one instance exists
Builder Pattern - Constructing complex objects step by step
Prototype Pattern - Cloning objects efficiently
Factory Pattern
Provides an interface for creating objects without specifying their exact class.
The Problem I Had
In my Agentic LLM project, I needed to create different LLM providers based on configuration:
My Solution: Factory Pattern
I created a factory to encapsulate provider creation:
Benefits I Gained
Decoupling: AgentService doesn't know about concrete provider classes
Easy extension: Adding new providers doesn't change client code
Centralized creation: All provider logic in one place
Testability: Easy to inject mock providers
Singleton Pattern
Ensures a class has only one instance and provides global access to it.
The Problem I Had
In my IoT monitoring platform, I had multiple components trying to create database connections:
My Solution: Singleton Pattern
I ensured only one database connection exists:
Thread-Safe Singleton (Bonus)
For environments with concurrent access, here's a thread-safe version:
When to Avoid Singletons
Singletons can make testing harder. Here's my approach:
Builder Pattern
Constructs complex objects step by step.
The Problem I Had
In my MCP server project, I needed to build complex HTTP requests with many optional parameters:
My Solution: Builder Pattern
I created a fluent builder interface:
Real-World Example: Query Builder
Here's how I use the builder pattern for database queries in my IoT platform:
Prototype Pattern
Creates new objects by cloning existing ones.
The Problem I Had
In my IoT platform, I needed to create sensor configurations that were mostly similar but with slight variations:
My Solution: Prototype Pattern
I implemented cloneable configurations:
Advanced: Prototype Registry
For my MCP server, I created a registry of configuration prototypes:
Combining Patterns: Real Example
Here's how I combined multiple creational patterns in my Agentic LLM project:
When to Use Each Pattern
Factory Pattern
✅ Use when:
You need to create different types of objects based on input
Object creation logic is complex
You want to decouple client code from concrete classes
❌ Avoid when:
You only have one type of object
Creation logic is trivial (just use new)
Singleton Pattern
✅ Use when:
You genuinely need exactly one instance (database connection, config)
The instance needs global access
Instance creation is expensive
❌ Avoid when:
Testing is important (singletons make testing harder)
You might need multiple instances later
Can use dependency injection instead
Builder Pattern
✅ Use when:
Objects have many optional parameters
Construction requires multiple steps
You want readable, fluent APIs
❌ Avoid when:
Objects are simple with few parameters
Construction is straightforward
Prototype Pattern
✅ Use when:
Creating new objects is expensive
You need variations of similar objects
Object initialization is complex
❌ Avoid when:
Objects are simple to create from scratch
Deep cloning adds unnecessary complexity
Conclusion
Creational patterns give you flexible ways to create objects:
Factory: Abstracts object creation
Singleton: Ensures single instance
Builder: Constructs complex objects clearly
Prototype: Clones objects efficiently
I use these patterns daily in my TypeScript projects. The key is applying them where they add value, not using them everywhere just because they exist.
// ✅ BETTER: Dependency injection for testability
class LoggerService {
private static instance: LoggerService;
private constructor() {}
static getInstance(): LoggerService {
if (!LoggerService.instance) {
LoggerService.instance = new LoggerService();
}
return LoggerService.instance;
}
log(message: string): void {
console.log(`[${new Date().toISOString()}] ${message}`);
}
}
// Instead of using the singleton directly, inject it
interface ILogger {
log(message: string): void;
}
class LoggerAdapter implements ILogger {
log(message: string): void {
LoggerService.getInstance().log(message);
}
}
class SensorService {
constructor(private logger: ILogger) {} // Dependency injection
async processSensor(sensor: Sensor): Promise<void> {
this.logger.log(`Processing sensor ${sensor.id}`);
// Process sensor
}
}
// Production
const service = new SensorService(new LoggerAdapter());
// Testing
class MockLogger implements ILogger {
logs: string[] = [];
log(message: string): void {
this.logs.push(message);
}
}
const mockLogger = new MockLogger();
const testService = new SensorService(mockLogger);
// Easy to verify logs without singleton interference
// ❌ BAD: Constructor with too many parameters
class SecurityScanRequest {
constructor(
public host: string,
public ports: number[],
public timeout: number,
public includeSSL: boolean,
public includeDNS: boolean,
public includeWhois: boolean,
public retryAttempts: number,
public concurrency: number,
public userAgent?: string,
public proxyUrl?: string,
public headers?: Record<string, string>
) {}
}
// Ugly usage with many undefined/null values
const request = new SecurityScanRequest(
'example.com',
[80, 443],
5000,
true,
false,
false,
3,
5,
undefined,
undefined,
undefined
);
// ✅ GOOD: Builder pattern
class SecurityScanRequest {
host: string;
ports: number[] = [];
timeout: number = 5000;
includeSSL: boolean = false;
includeDNS: boolean = false;
includeWhois: boolean = false;
retryAttempts: number = 3;
concurrency: number = 5;
userAgent?: string;
proxyUrl?: string;
headers?: Record<string, string>;
private constructor() {
this.host = '';
}
static builder(): SecurityScanRequestBuilder {
return new SecurityScanRequestBuilder();
}
}
class SecurityScanRequestBuilder {
private request: SecurityScanRequest;
constructor() {
this.request = new SecurityScanRequest();
}
forHost(host: string): this {
this.request.host = host;
return this;
}
onPorts(ports: number[]): this {
this.request.ports = ports;
return this;
}
withTimeout(timeout: number): this {
this.request.timeout = timeout;
return this;
}
includeSSLCheck(): this {
this.request.includeSSL = true;
return this;
}
includeDNSLookup(): this {
this.request.includeDNS = true;
return this;
}
includeWhoisLookup(): this {
this.request.includeWhois = true;
return this;
}
withRetries(attempts: number): this {
this.request.retryAttempts = attempts;
return this;
}
withConcurrency(concurrency: number): this {
this.request.concurrency = concurrency;
return this;
}
withUserAgent(userAgent: string): this {
this.request.userAgent = userAgent;
return this;
}
withProxy(proxyUrl: string): this {
this.request.proxyUrl = proxyUrl;
return this;
}
withHeaders(headers: Record<string, string>): this {
this.request.headers = headers;
return this;
}
build(): SecurityScanRequest {
if (!this.request.host) {
throw new Error('Host is required');
}
if (this.request.ports.length === 0) {
throw new Error('At least one port is required');
}
return this.request;
}
}
// Clean, readable usage
const request = SecurityScanRequest.builder()
.forHost('example.com')
.onPorts([80, 443, 8080])
.withTimeout(10000)
.includeSSLCheck()
.includeDNSLookup()
.withRetries(5)
.withConcurrency(10)
.build();
// Simple case is still simple
const simpleRequest = SecurityScanRequest.builder()
.forHost('example.com')
.onPorts([443])
.build();
