How the Factory Pattern Simplifies Salesforce Implementations for specific Logic

As organizations scale and expand across regions or manage multiple business units, their Salesforce implementations can quickly become complex, requiring unique processes, validation rules, or business logic depending on the country or record type in use. Managing this complexity without creating technical debt is critical, and one of the most effective tools to achieve this is the Factory Pattern.

The Factory Pattern is a creational design pattern that provides an efficient way to instantiate different classes based on input criteria—like country, record type, or business unit—without hardcoding logic or cluttering your codebase with conditionals. In this article, I’ll dive into how the Factory Pattern can be applied to streamline Salesforce implementations, especially when dealing with region-specific or record type-specific business rules.

What is the Factory Pattern?

The Factory Pattern provides a mechanism to create objects without specifying the exact class of object that will be created. It abstracts the process of object creation, allowing you to defer the instantiation of objects to subclasses.

In practical terms, this means that if you need different business logic for various countries or record types in Salesforce, the Factory Pattern can dynamically select and instantiate the appropriate class, ensuring that the correct logic is applied.

Instead of having one large class with many if-else or switch statements to determine which logic applies, the Factory Pattern allows you to centralize this logic, making the system cleaner and easier to extend as new countries or record types are added.

Why is the Factory Pattern Important for specific Logic?

1. Eliminating Complex Conditional Logic

In Salesforce implementations, it’s common to encounter scenarios where business rules differ depending on the country or the record type. Without using a pattern like Factory, developers often write large conditional blocks (if-else, switch-case statements) to handle these differences. This leads to monolithic classes that are hard to maintain and scale.

For example, imagine a scenario where a company has different approval processes for record types like "Enterprise" and "SMB," or varying tax calculations for orders based on the country. Without the Factory Pattern, these conditions would have to be managed manually with conditionals, cluttering the code and making it harder to modify or extend.

By applying the Factory Pattern, you can abstract these conditions and let the Factory select the appropriate class that implements the logic for each record type or country. This keeps the code clean and modular, and reduces the chances of introducing bugs when adding new logic.

2. Easier Maintenance and Extensibility

As businesses expand into new markets or add more record types, the complexity of the Salesforce org grows. The Factory Pattern makes it easy to add new classes to handle country-specific logic without modifying existing code. This is especially valuable for large, global implementations where the requirements for different countries may evolve over time.

For example, when a new country with unique tax regulations is introduced, all you need to do is create a new class that implements the business logic for that country. The Factory will instantiate this class when required, leaving the rest of the codebase untouched.

This approach makes it easier for teams to maintain the codebase because each class is responsible for a single set of country or record type-specific rules. Additionally, extensibility is simplified—adding support for a new country or record type involves creating a new class rather than modifying the logic in multiple places.

3. Improved Code Reusability

The Factory Pattern promotes the reusability of components. Instead of duplicating code across various conditional blocks to handle country or record type-specific logic, you create independent classes for each scenario that the Factory can instantiate as needed.

For instance, if you have similar validation logic for multiple countries, you can create a base validation class and have country-specific subclasses extend that logic. The Factory would then instantiate the correct subclass based on the country. This modular design reduces code duplication and improves reusability.

4. Separation of Concerns

Using the Factory Pattern adheres to the Single Responsibility Principle (SRP)—each class only handles its specific logic, such as country-specific tax calculations, record type-specific approval processes, or custom workflows. This separation of concerns keeps the system organized and makes it easier to debug or update parts of the system.

For example, if there’s a bug in the tax calculation logic for a specific country, you know exactly where to look—at that country’s specific class—rather than combing through a large, monolithic class filled with conditionals.

5. Reducing Hardcoded Logic with Dynamic Instantiation

One of the key advantages of the Factory Pattern is its ability to dynamically instantiate classes based on input parameters—such as the country or record type—without needing to hardcode each possibility. By leveraging Apex's Type.forName() method, we can dynamically instantiate classes, making the Factory more scalable and reducing the need to modify the core codebase as new countries or record types are added.

Real-World Example: Using the Factory Pattern for Record Types

Consider a scenario where a global company has different sales processes based on the record type of an Opportunity in Salesforce. An "Enterprise" opportunity might follow a more complex approval process, while an "SMB" opportunity might have a simpler workflow. With the Factory Pattern, you can define different classes for each record type's business logic, like this:

1. Create the Interface:

public interface OpportunityHandler {
    /**
     * @description Processes the given Opportunity.
     *
     * @param opp The Opportunity instance to be processed.
     */
    void processOpportunity(Opportunity opp);
}        

2. Create Handler Classes:

public class EnterpriseOpportunityHandler implements OpportunityHandler {
    /**
     * Processes the given Enterprise Opportunity.
     *
     * @param opp The Opportunity to be processed.
     */
    public void processOpportunity(Opportunity opp) {
        // Logic for Enterprise Opportunity
        System.debug('Processing Enterprise Opportunity');
    }
}

/**
 * @description SMBOpportunityHandler class implements the OpportunityHandler interface
 * and provides specific logic for processing SMB Opportunities.
 */
public class SMBOpportunityHandler implements OpportunityHandler {
    /**
     * Processes the given SMB Opportunity.
     *
     * @param opp The Opportunity to be processed.
     */
    public void processOpportunity(Opportunity opp) {
        // Logic for SMB Opportunity
        System.debug('Processing SMB Opportunity');
    }
}        

3. Create the Dynamic Factory Class:

public class OpportunityHandlerFactory {

    // Retrieve the correct handler using custom metadata
    public static OpportunityHandler getHandler(String criteria) {
        // Query the custom metadata for the matching criteria
        HandlerMapping__mdt handlerMetadata = [SELECT HandlerClass__c FROM HandlerMapping__mdt WHERE Criteria__c = :criteria LIMIT 1];

        if (handlerMetadata == null || String.isBlank(handlerMetadata.HandlerClass__c)) {
            throw new CustomException('No handler found for criteria: ' + criteria);
        }

        // Dynamically instantiate the class based on the class name from metadata
        String className = handlerMetadata.HandlerClass__c;
        Type handlerType = Type.forName(className);

        if (handlerType != null) {
            return (OpportunityHandler) handlerType.newInstance();
        } else {
            throw new CustomException('Handler class not found: ' + className);
        }
    }
}        

4. Usage in Trigger or Class

Opportunity opp = [SELECT Id, RecordType.Name FROM Opportunity WHERE Id = :someOpportunityId];
OpportunityHandler handler = OpportunityHandlerFactory.getHandler(opp.RecordType.Name);
handler.processOpportunity(opp);        

Why using Salesforce Low Code improves the pattern?

By combining formula fields and custom metadata, you can further enhance this process by allowing Salesforce admins to easily configure the system without modifying code. Formula fields allow you to dynamically calculate the criteria for selecting the correct handler, while custom metadata enables a highly configurable and declarative way of mapping these criteria to handler classes.

1. Dynamic and Declarative Criteria Calculation

When you have multiple fields or conditions that determine which handler class to instantiate, formula fields can dynamically calculate the criteria. For example, you might need to select a handler based on a combination of record type and country. A formula field allows you to centralize this logic in a declarative way, avoiding complex conditional logic in Apex code.

This calculated criteria is then used to look up the correct handler class in custom metadata, making the solution both flexible and maintainable.

2. No Code Changes for New Logic

By using custom metadata to map criteria to handler classes, you allow non-developers (admins) to update the logic without requiring code changes. When a new record type or country-specific handler is introduced, admins can simply add a new metadata record, reducing the need for continuous development efforts.

3. Centralized and Simplified Logic

The combination of formula fields and custom metadata helps centralize logic, making it easier to understand and manage. Instead of spreading logic across multiple places in your code, the criteria are calculated in one place (formula field), and the handler logic is configurable through metadata.

Benefits of Using Custom Metadata in the Factory Pattern

• No Code Changes for New Logic: By using custom metadata, you can add new handlers for different countries or record types without modifying the Apex code. Just create a new metadata record with the appropriate mapping.
• Improved Maintainability: Metadata-driven design makes the system more maintainable. Updates to logic can be handled by admins without requiring developers to write new code.
• Dynamic and Scalable: This approach makes the system more flexible. You can scale it easily as the business grows by simply adding new metadata entries.

Conclusion: Factory Pattern as a Powerful Tool for Complex Implementations

The Factory Pattern is a powerful tool that allows Salesforce architects and developers to simplify complex implementations that require specific logic. By centralizing object creation and delegating responsibilities to separate classes, it provides a flexible, scalable, and maintainable solution that is easy to extend as business requirements evolve.

If you’re managing complex Salesforce implementations with varying business rules, leveraging the Factory Pattern can save time, reduce technical debt, and ensure your system remains agile as your business grows.

Interesting links to learn more about this pattern

• https://www.sfdcblogs.com/post/factory-design-pattern-in-apex
• https://medium.com/@s.shubhamjagatap/mastering-salesforce-design-pattern-factory-method-design-pattern-day-3-35165e7cfd68
• https://salesforcecodex.com/salesforce/implement-factory-design-pattern-in-salesforce-apex/