You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Apex Design Patterns


By: Venkata

Singleton:

Repeated execution of a class within a single transaction may lead to exceed the governor limit. This pattern is to reduce repeated instantiation of a class.

Strategy:

Strategy pattern is to provide different solutions for the same problem at runtime.

Decorator:

Generally, this pattern is used to provide the additional functionality to the sObject using Apex code.

Bulk State Transition: Implementing Bulk State transition ensure that the bulk action is performed based on the change of bulk record state.

Singleton pattern 

The use case of the singleton pattern is to create only one instance of a class per transaction. Consider the following scenario, I have two custom objects, “products” and “customer”. The “customer” object has “Customer Name” (Text field), “Type” (Picklist field with values Car, Bus and Bike) and a lookup field named “Product Name” to the Product Object. The “products” object has “Product Name” (Text field), “Product No” (Text field), “Amount” (Currency field).

Whenever the customer provides the Type as “Car”, then the record should be associated with the “car” products. The following is the implementation code.

Trigger 

trigger CustomerTrigger_AT on Customer__c (before insert) { 

    for(Customer__c cust: Trigger.new){ 

         if(cust.Type__c == 'Car'){ 

        //Instantiate the Carproduct_AC class to get Car product Id. 

         CarProduct_AC carId = new CarProduct_AC(); 

         cust.ProductName__c = carId.recordId;   

         }   

    } 

}

Class 

public class CarProduct_AC{ 

    public String recordId {get; private set;} 

    public CarProduct_AC(){ 

    //To get the record Id for a product named “Car”.  

    //If a trigger is executed in bulk, it exceeds the SOQL limitation. 

           recordId = [SELECT Id FROM Products__c WHERE Name = 'CAR'].Id; 

    } 

}

In the above trigger, for each record it calls the Apex class “CarProduct_AC”. It exceeds the Apex SOQL limitation for the bulk transaction and throws “CustomerTrigger: System.LimitException: Too many SOQL queries: 101” error. To overcome this problem, we are going with the singleton design pattern. The method in this class need not to run for each record. It will provide the car’s record Id when it runs for the first time. So, here we have stopped the class from recursive execution using Singleton pattern.

Trigger 

trigger CustomerTrigger_AT on Customer__c (before insert, before update) { 

    for(Customer__c cust : Trigger.new){ 

         if(cust.Type__c == 'Car'){ 

         //Instantiate the Carproduct_AC class to get Car product Id. 

         CarProduct_AC carId = CarProduct.getinstance(); 

         cust.ProductName__c = carId.recordId;   

         }   

    } 

}

 Singleton Class 

public class CarProduct_AC{ 

    //Static variable to refer to the class instance 

    private static CarProduct_AC instance = null; 

    //Private constructor to get the record Id. 

    public String recordId {get;private set;} 

    private CarProduct_AC(){ 

        //To get the record Id for car product.  

        recordId = [SELECT Id FROM Products__c WHERE Name = 'CAR'].Id; 

    } 

    public static CarProduct_AC getInstance(){ 

        if(instance == null) instance = new CarProduct_AC(); 

        return instance; 

    } 

}

For a single transaction, the query gets executed only once. This is because we are not instantiating the CarProduct_AC for each customer’s record insert, it gets instantiated only once per transaction.
Strategy Pattern 

The strategy pattern is ensuring that different set of solutions is available for a same problem. It chooses the appropriate solution based on the user input at the runtime. Let’s consider the Opportunity object with Type picklist has values Discount 1 and Discount 2. Our goal is to calculate and apply a unique discount percentage for the opportunity amount based on the selected Type.

Discount Logic: 

Discount 1 – Opportunity created date is from 1 to 15 of any month, discount = 5%.

Discount 1 – Opportunity created date is from 15 to end of any month, discount = 10%

Discount 2 – Opportunity created date is from 1 to 15 of any month, discount = 15%.

Discount 2 – Opportunity created date is from 15 to end of any month, discount = 20%

The following code shows how the strategy pattern provides the different set of solutions with code reusability at runtime. I used custom setting to map opportunity type and apex class (different solution based on type) to provide the solution.

Context Class 

This class decides the solution at runtime based on user requirement.

public class OpportunityTypeContext_AC { 

    Map<Id,Opportunity> opportunityMap = new Map<Id,Opportunity>();     

    public void onBeforeInsert(List<Opportunity> opportunityList){ 

        for(Opportunity opp : opportunityList){ 

          //Get the opportunity with Discount 1 and Discount 2 values 

            if(opp.Amount != null && opp.Type != null && (opp.Type == 'Discount 1' || 

                                                                                                 opp.Type == 'Discount 2')){ 

                opportunityMap.put(opp.Id,opp); 

            } 

        } 

        if(opportunityMap.size() > 0) { 

            applyDiscount(opportunityMap);  

        } 

    }   

    //Apply discount based on opportunity type 

    public void applyDiscount(Map<Id,Opportunity> opportunityMap){ 

        Integer day;  

        for(Opportunity opp : opportunityMap.values()){ 

            if(Trigger.isInsert){ 

                day = system.today().day(); // to get day from dateTime  

            } 

            OpportunityDiscountMapping__c  oppDiscount; // instance for remote setting 

          // Get class name from custom setting  

           oppDiscount = OpportunityDiscountMapping__c.getValues(opp.Type);   

            Type className = Type.forName(oppDiscount.Value__c);            

            //Dynamically calls apex class 

            OpportunityTypeInterface_AC oppInterface = (OpportunityTypeInterface_AC) 

                                                                                               className.newInstance(); 

            Integer discount = oppInterface.applyDiscount(day); 

            opp.Amount = opp.Amount - (discount*opp.Amount/100); // appply discount 

        } 

    } 

}

Strategy Interface Class 

An interface class defines a method that needs to be implemented by all the concrete strategy classes.

public interface OpportunityTypeInterface_AC{ 

    Integer applyDiscount(Integer day); 

}

Concrete Strategy classes 

A group of class that implements a strategy interface. Each class provides a unique solution for the problem. Based on the input type, the class gets called by the context class at runtime.

Solution 1 

public class Discount1Controller_AC implements OpportunityTypeInterface_AC{ 

   public integer applyDiscount(Integer day){ 

        if(Day<=15){ 

            return 5; // discount percentage of days between 1 to 15 of any months             

        } 

        else{ 

            return 10; // discount percentage for remaining days 

        } 

    } 

}

Solution 2 

public class Type2DiscountController_AC implements OpportunityTypeInterface_AC{ 

 public integer applyDiscount(Integer day){ 

        if(Day<=15){ 

            return 15; // discount percentage of days between 1 to 15 of any months 

        } 

        else{ 

            return 20; // discount percentage of remaining days 

        } 

    } 

}

Here the classes are interchangeable at runtime and provide the solutions which suits the user requirements.

Decorator Pattern 

In some scenario, we need to show the value only in UI level, but not to store that value in Database. Here we have a Decorator Design pattern to solve this kind of problems. This pattern provides the decorator class which wraps the apex class to provide the extended functionality for the sObject.

Consider the problem in which we should display the Product value in INR using Visualforce page, but the actual value is in USD. We are going to use the custom object “products” with “Name”(Text) and “Amount”(Currency in dollar) field.

Apex Class 

public class ConvertCurrency_AC{ 

    public List<ProductDecorators_AC> ConvertedCurrency{set; get;} 

    public ConvertCurrency_AC(){ 

        //get all the products and its amount. 

        List<Products__c> productDetail = [SELECT Name, Amount__c  FROM Products__c]; 

        if(productDetail .size() > 0){ 

            ConvertedCurrency = new List<ProductDecorators_AC>(); 

            for(Products__c product: productDetail ){ 

                //passing parameter to the decorator class to get the converted currency. 

                ConvertedCurrency.add(new ProductDecorators_AC(product)); 

            } 

        } 

    } 

}

The following class shows how the Products__c object is wrapped. This object does not have the field to show the value in INR. The Decorator class is used to display the USD in INR.

Decorator Class 

public class ProductDecorators_AC{ 

    //assume the INR value per dollar as 64.78  

    private Double DOLLAR_INR = 64.78; 

    public String ProductName{get;set;} 

    public Double productInDollar {get;set;} 

    public Double productInInr {get;set;} 

    public ProductDecorators_AC(Products__c product){ 

        ProductName = product.Name; 

        productInDollar = product.Amount__c; 

        //converting USD to INR 

        productInInr = productInDollar * DOLLAR_INR; 

    } 

}

VisualForce Page 

<apex:page controller="ConvertedAmount"> 

    <apex:form > 

        <apex:pageBlock title="Product Details"> 

            <apex:pageBlockTable value="{!ConvertedCurrency}" var="convertAmount"> 

                <apex:column headerValue="Product Name" value="{!convertAmount.ProductName}"/> 

                                <apex:column headerValue="Amount in Dollar" value="{!convertAmount.productInDollar}"/> 

                <apex:column headerValue="Amount in Inr" value="{!convertAmount.productInInr}"/> 

            </apex:pageBlockTable> 

        </apex:pageBlock> 

    </apex:form> 

</apex:page>

Output:

The VisualForce page displays the value product Name and Amount from the database. It also displays the converted currency value in INR.

Bulk State Transition 

The Bulk state transition pattern is used to perform bulk actions in Apex based on DML actions. It improves the code reusability and only the record which meets the criteria is allowed to be processed.

For example, consider the following code.

Trigger 

trigger CaseTrigger_AT on Case (after insert, after update) { 

    for(Case newcase : Trigger.new){ 

        if(newcase.Status == 'new'){ 

            Task tsk = new task(); 

            tsk.WhatId = cs.Id; 

            tsk.Subject = 'New Task'; 

            tsk.Priority = 'High'; 

            tsk.Status = 'Not Started'; 

            insert tsk; 

        } 

    } 

}

The above code has the following issue.

  • It is not based on DML type. Whenever the record gets updated without any change in the status of the case, the trigger gets executed unnecessarily.
  • There is no bulk handling. The code exceeds the DML governor limit per transaction when it is used for bulk transaction.
  • The code is not reusable.

The bulk state transition requires a trigger that allows only the eligible record that have changed its state and a utility class to implement the logic. The trigger needs to be framed by its events and the DML type. The following examples show the bulk state transition.

Trigger

trigger CaseTrigger_AT on Case (after insert, after update) { 

    if (Trigger.isAfter && (Trigger.isInsert || Trigger.isUpdate)) { 

        List<case> newCaseList = new List<case>(); 

        for (case newcase : trigger.new) { 

            // check the current and prie state for trigger update  

            if (newcase.Status == 'new' && (trigger.isInsert ||  

                                       (trigger.isUpdate && 

                                        trigger.oldMap.get(newcase.id).Status != 'new'))) 

                newCaseList.add(newcase); 

        } 

        if (!newCaseList.isEmpty()) { 

            TaskCreation_AC task = new TaskCreation_AC(); 

            task.createTask(newCaseList);//parameter passing to the TaskCreation_AC class 

        }   

    } 

}

Class 

public class TaskCreation_AC { 

    List<Task> taskList = new List<Task>(); 

    public void createTask(List<case> caseList){ 

        for(Case newcase : caseList){ 

            Task tsk = new task(); 

            tsk.WhatId = newcase.Id; 

            tsk.Subject = 'New Task'; 

            tsk.Priority = 'High'; 

            tsk.Status = 'Not Started'; 

            taskList.add(tsk); 

        } 

        if(!taskList.isEmpty()){ 

            insert taskList;    

        } 

    } 

}

In the above mentioned code the trigger passes the records which meets the condition to the utility class. The trigger is framed with trigger events and the DML type. The utility class can be reused in future.

Conclusion 

We have implemented the singleton, strategy, decorator and Bulk State Transition with the scenario we faced. There are other patterns are available like Facade pattern and Composite Design Pattern. We should find the pattern which suits our problem and implement it to make our code optimizable, maintainable and reusable.