Design Patterns in Salesforce: Deep Dive into Singleton and Factory
When developing applications in Salesforce, developers often face challenges such as:
-
Avoiding repeated SOQL queries and redundant object creation
-
Maintaining clean, reusable, and scalable code
-
Supporting multiple implementations (e.g., Email, SMS, Push notifications) without breaking existing logic
This is where design patterns come in.
Design patterns are standard, reusable solutions to common software design problems. They don’t provide code directly but give you a proven approach to structure your logic.
In this blog, we’ll dive deep into two popular design patterns in Salesforce Apex:
-
Singleton Pattern
-
Factory Pattern
We’ll cover:
-
What they are
-
Why they matter in Salesforce
-
How they work (with Apex code examples)
-
Practical Salesforce use cases
-
How they can even be combined
🔹 What is the Singleton Pattern?
The Singleton pattern ensures that only one instance of a class exists during a single Salesforce transaction.
👉 Think of it like Salesforce’s Governor Limits: since resources are limited, you don’t want to repeatedly query the same data or create the same object multiple times in a single execution context.
⚙️ How Singleton Works
-
Private constructor → prevents direct instantiation of the class.
-
Static variable → stores the single instance.
-
Public static method → provides global access to the instance.
✅ Apex Example: Singleton for Organization Settings
Suppose you need the Org Name and Default Currency multiple times in a trigger, batch, or controller. Instead of running the SOQL query every time, the Singleton ensures:
-
Only one query runs per transaction
-
The data is reused globally
-
You save on SOQL governor limits
🔹 What is the Factory Pattern?
The Factory pattern is a creational pattern that lets you create objects without exposing the creation logic to the client.
Instead of using if-else
or switch
statements everywhere in your code, the Factory centralizes object creation. This makes your code cleaner, extensible, and easier to maintain.
⚙️ How Factory Works
-
Define a common interface (or abstract class).
-
Create multiple implementations of that interface.
-
Use a Factory class to decide which implementation to return at runtime.
✅ Apex Example: Factory for Notifications
📌 Salesforce Use Case:
Imagine a Case Escalation process where customers can be notified via Email or SMS depending on their preferences.
Instead of writing:
all over your code, you simply call:
If a new channel (like WhatsApp) is added later, you just:
-
Create a new
WhatsAppNotification
class implementingNotification
. -
Update the
NotificationFactory
.
No need to touch the main business logic.
🔹 Combining Singleton and Factory
In some cases, you may want to ensure that only one factory instance exists across the transaction (for efficiency).
✅ Example: Singleton Factory
📌 Real-World Salesforce Use Case
🔔 Case Management Notification System
-
The system decides the notification channel at runtime (Factory).
-
Only one instance of the factory should exist during a transaction to prevent repeated initialization (Singleton).
So, when a Case escalates:
This ensures efficiency + flexibility in one design.
🚀 Key Takeaways
-
Singleton Pattern
-
Ensures only one instance per transaction
-
Useful for caching, org-wide settings, and reducing SOQL queries
-
-
Factory Pattern
-
Centralizes object creation logic
-
Useful for dynamic behavior like notifications, integrations, payment gateways
-
-
Combination
-
Singleton Factory provides both performance optimization and scalability
-
By using these patterns, Salesforce developers can build enterprise-grade, maintainable, and scalable applications that adhere to best practices and respect governor limits.