The Universal Call Center company is growing very fast, and they have a small Force.com application where agents can log a request to place an order for a new computer. Developers have just learned about the factory method design pattern and are very excited to implement the same design pattern in this scenario as well. They decided to create an interface of the computer type and its different implementations, such as high-configuration and low-configuration computers. However, they were disappointed when they heard that they need to support various types of configurations other than low and high configurations. For example, some computers need high end processors but small monitors and less storage. There were a few requests regarding an average processor but an LCD monitor and SSD storage.

By this time, developers realized that the factory method pattern cannot be used in this scenario. Let's see how they solved this problem.

The abstract factory pattern...

The singleton design pattern restricts the instantiation of a class to only one object.

This is a useful design pattern in Apex and is frequently used. As discussed in the previous chapter, Salesforce has various governor limits; for example, a number of SOQL queries, a number of query rows returned, and a number of DML operations that can be performed in a single request.

Using the singleton design pattern, we can make sure that utility classes are instantiated only once, which can help in avoiding governor limits.

The sales division of a call center receives calls either from a customer or broker who is interested in the product. If a call comes directly from a customer, then the call center agents need to create a new opportunity record with all the required information. Alternatively, if a call comes from a broker, then the call center agents need to create an opportunity record and then record it for a broker as well. Brokers are eligible for commission...

The builder pattern is used to instantiate an object of a complex class using the step-by-step approach and return a constructed object at once.

The intention of the factory method and abstract factory method patterns is to use polymorphism to construct objects, as discussed in the initial part of this book. However, in this design pattern, a new independent Builder class is used to construct objects. This pattern is very useful when many parameters are needed to construct and initialize an object.

Developers of Universal Call Center were enjoying their success after the implementation of the singleton pattern and resolving excess SOQL queries. Now, it was time to write a test class for the code written in the singleton design pattern.

Developers came up with the following test class:

@isTest(SeeAllData = false) 
public class OpportunityTriggerTest { 
     
    //Test method to test if state is populated 
    //on Opportunity and Brokers 
    static testMethod void validateState...

The prototype design pattern is used to create a new object of a class based on an existing object of the same class. It helps avoid the repetitive code used to initialize a newly created object.

Developers of Universal Call Center solved many problems associated with the creation of an object, using design patterns, such as the factory method, singleton, abstract factory method, and builder pattern. Now, they are confident about how to simplify, manage, and solve problems created while instantiating objects. They were working on the module of an application where they needed to create a duplicate copy of the Apex helper class used to perform various operations.

The following is a code snippet of a wrapper class, which simply sets and gets the Opportunity object:

public class OpportunityWrapper { 
     
    private Opportunity opp ; 
     
    public void setOpportunity(Opportunity o){ 
        opp = o ; 
    } 
     
    public Id getOpportunityId() 
    { 
   ...