Dynamic calling of Apex classes

 

Dynamic class invocation in Apex refers to the ability to call methods or instantiate classes at runtime using their names as strings, rather than hardcoding the specific class name or method. This provides flexibility and makes it easier to handle various objects and behaviors in a generic way.

Key Concepts:

1. Dynamic Class Instantiation:

   • Apex allows you to instantiate classes dynamically based on their names. This is particularly useful when you have to interact with different types of classes but don't want to explicitly reference each class.

2. Dynamic Method Invocation:

   • You can invoke methods dynamically by using Type and Method classes, and the Reflection mechanism in Apex, enabling you to call methods based on the method name at runtime.

3. Use of Type.forName:

   • Apex has the Type class, which allows you to reference a class by its string name. Using Type.forName('Namespace.ClassName'), you can dynamically create objects or invoke methods.

4. Polymorphism:

• You can leverage polymorphism to call methods on different classes that implement the same interface, even if the exact class isn’t known until runtime.

Why Use Dynamic Class Invocation in Apex?

Dynamic class invocation provides flexibility and scalability in your code. Here are a few reasons to use it:

1. Handling Multiple Classes:

   • In scenarios where you need to process different sObjects (like Account, Contact, etc.) dynamically, you can use dynamic class invocation to call a handler for each specific sObject type without explicitly writing the code for each type.

   Example:

   • Instead of writing separate methods for processing Account, Contact, Opportunity, etc., you can dynamically call the respective handler classes based on the type of the incoming object.

2. Scalability:

   • When the business logic requires flexibility to handle many types of records (sObjects) that implement a common interface, dynamic invocation allows you to scale easily by adding new classes without changing existing code.

3. Reduced Code Duplication:

   • Dynamic invocations allow you to avoid duplicating code for each class. Instead of writing individual logic for each class, you can write a generic handler and invoke class methods dynamically based on the object type.

4. Flexibility in Test Environments:

• It can be useful in testing and writing reusable components. For instance, if you want to dynamically test multiple classes without changing code for each, you can invoke the appropriate class or method dynamically based on the context.

Demo Code:

Interface class:

public interface globalHandler {

    void processRecord(List<SObject> record);

}

Create Handler Classes:

AccountHandler

public class AccountHandler implements globalHandler{

    public void processRecord(List<SObject> record) {

        System.debug('Processing AccountRecords: ' + record);

    }

}

ContactHandler

public class ContactHandler implements globalHandler{

    public void processRecord(List<SObject> record) {

        System.debug('Processing Contact Record: ' + record);

    }

}

Map Handlers Dynamically:

public DynamicClassInvoker invokeHandler(List<SObject> sObj) {

        for(sObject sObjectValue  : sObj){

            String sObjectType = sObjectValue.getSObjectType().getDescribe().getName();

             if (handlerMap.containsKey(sObjectType)) {

                handlerMap.get(sObjectType).processRecord(sObj);

            } else {

                System.debug('No handler found for sObject type: ' + sObjectType);

            }

        }

        return this;

    }

Calling Code:

List<sObject> passingParam = new List<sObject>(); List<Contact> contactRecords = [SELECT Id FROM Contact]; List<Account> accounts = [SELECT Id from Account LIMIT 10]; passingParam.addAll(accounts); passingParam.addAll(contacts); DynamicClassInvoker callGlobal = new DynamicClassInvoker(); callGlobal.invokeHandler(passingParam);

How It Works:

1. Invoke Handler:

   • The invokeHandler method receives a List<SObject> and iterates through it.

   • For each SObject in the list, the method checks its type (sObjectType).

   • It then checks if a handler exists for that type in the handlerMap. If found, it calls processRecord on the handler and passes the entire list of SObjects (sObjList).

2. Handler Classes:

   • Each handler (like AccountHandler or ContactHandler) now processes a list of SObjects.

   • Inside the processRecord method, we loop through the passed list and cast the SObject to the appropriate object type (Account or Contact).

   • This allows the handler to work with multiple records at once.

3. Why the List:

   • By passing the entire List<SObject> to the handler, you enable the handler to process multiple records at once, which is often more efficient (e.g., when performing DML operations or aggregating data for a batch).