Single Ton Design Pattern in Apex

Design Pattern:

~~~~~~~~~~~

Design Pattern is a theoretical solution for re-occurring problems in Software Design.

In this Post, We are going to discuss about SingleTon Design Pattern.

SingleTon Design Pattern:

~~~~~~~~~~~~~~~~~~~

This Pattern talks about creating a Single instance for a class.

In Apex, This Design Pattern is mostly used to avoid governor (SOQL ,DML) limits.

Implementation of SingleTon Design Pattern:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Below are the rules to create SingleTon Design pattern.

• Class Design
• Object
• Static Method
• Public Method

1.Class Design:

~~~~~~~~~~~~

The object for the class should not be created outside the class.

For eg: if we have a class called SingleTon.

class SingleTon
{
 //Object for this class needs to be created inside the class only
}

Therefore, to avoid creating the object outside the class, Constructor should be marked private as below.

class SingleTon
{
 private SingleTon()
 {

 }
}

2.object
~~~~~~~~~
Object instantiation statement should be private and static. Also, initialize the object with null.
Below is the example:

class SingleTon
{
 private static SingleTon =null;
 private SingleTon()
 {

 }
}

3.Static Method:
~~~~~~~~~~~~~~~~~~
A Public Static method has to be created in the object which initializes the object.

class SingleTon
{
 private static SingleTon st=null;
        private SingleTon()
 {

 }
 public static SingleTon getInstance()
 {
   if(st==null)
   {
     st=new SingleTon();
     return st;
   }
   else return st;
 }
}

The above method checks if already an object is created, if so, the method returns the created object otherwise it creates an object and returns the object created.

4.Public Method:

~~~~~~~~~~~~~~~~

This is the method which is being invoked from elsewhere depending upon the requirement.

class SingleTon
{
    public list<Sobject> lst;
    private static SingleTon st=null;
    private SingleTon()
    {

    }
    public static SingleTon getInstance()
     {
        if(st==null)
 {
     st=new SingleTon();
     return st;
  }
  else return st;
 }
    public list<Sobject> sampleMethod()
    {
   return lst;
    }
}

let us further check all these with examples:
In this scenario, Upon before and after insert events, We need to query on Account.
Trigger Design:
~~~~~~~~~~~~

Trigger Contactupdate on Contact(before insert,after insert)
{
  // creates reference to SingleTon class
 SingleTon st=SingleTon.getInstance(); 
 if(Trigger.isinsert&&Trigger.isAfter)
 {
   for(Contact c:Trigger.new)
   {
    obj.acclist; // Invokes static method in SingleTon class
    conhandler con=new conhandler(); //This invokes ConHandler
   }
 }
}

Class Design using Single Ton pattern:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Class SingleTon
{
 public list<Account> acclist;
 private static SingleTon st=null;       
 private SingleTon()
 {
   acclist=[select id,name from Account];
        }
       public static SingleTon getInstance()
       {
         if (st==null) 
         //This statement check if the object has already 
         instantiated
           {
            st=new SingleTon();  //here it instantiates
            return st;           // and returns the object.
           }
        else return st; 
        // if it is already instantiated, returns the object
      }
      public acclist()
      {
       return acclist; // This returns already records queried.
      }
}

Design for ConHandler:
~~~~~~~~~~~~~~~~~~

Class ConHandler
{
 public ConHandler()
 {
    M1(); //This constructor invokes M1()
 }
 public void M1()
 {
   update [select id,from Account]; //This method updates Account which fires event on Account Trigger
 }
}

Account Trigger
~~~~~~~~~~~~

Trigger AccountUpdate on Account(before update,after update)
{
 if(Trigger.isUpdate)
    {
        System.debug('inside account trigger ');
        SingleTon st = SingleTon.getInstance(); 
        // This again invokes Trigger Handler
        System.debug('Q3 '+ obj.conList());
    } 
}

Let us check this scenario with by inserting a Contact record.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

• When a record is inserted, Before Trigger gets executed and there is no event defined for before event, therefore, after DML, Trigger on contact fires for after event and creates an instance for SingleTon class.
• Now, let us look at SingleTon, As soon as SingleTon st=SingleTon.getInstance(); invokes, it calls static method in SingleTon class which is getInstance.
• Then, checks for reference 'st' if it is instantiated, as the value now is null, Therefore,"if" statement succeeds and creates an object. Therefore, the value of st is now instantiated.
• As soon as SingleTon invokes and an object is created, Constructor of SingleTon is invoked and queries on Account, Therefore, now acclist has account records.After the execution of getInstance method, Control goes back to SingleTon and variable "st" now has an object created.
• After that, Trigger checks for the event and enters the condition which invokes conlist, conlist from SingleTon returns account records which are queried in the constructor of the SingleTon.

Limits Consumed so far:
~~~~~~~~~~~~~~~~~~~~

• The value of "st" still exists though the class execution is done because this is static.., The scope of static method or variable continues until the execution of a transaction.
• Number of SOQL's queries executed is one.
• Next.., When ConHandler executes, This will update the Account record which invokes Triggers on Account. 
• Here the account trigger first checks for before update and again invokes SingleTon st = SingleTon.getInstance(); which returns st and also after update, it invokes SingleTon st = SingleTon.getInstance().

Limits Consumed so far:

~~~~~~~~~~~~~~~~~~

• SOQL Limits consumed so far: 1 
• if this Pattern would not have been followed, SOQL consumption would have been - 3

In this way, Singleton design pattern helps in reduces the consumption of governor limits.
Cons of SingleTon:
~~~~~~~~~~~~~~~~~~~~
1. Improper use of singleton leads to hit other governor limits. For example: In our example, there may be a chance to hit the "Heap size" limit error.
If you observe the " SingleTon" class the below statement is not declared as static but still, the state will be maintained between transactions
public List<Contact> conList = null; because object created for class is still available.

tHiNk gooD and dO thE bEsT.........MANJU NATH 🌝