design pattern Archives - Technical Potpourri from Sudipta Deb

APEX TRIGGER DESIGN PATTERN

by Sudipta Deb | Aug 11, 2015 | 501, best practice, design pattern, Trigger | 0

This post is part of the series – Design Pattern in ApexI know it was discussed number of times earlier about Apex Trigger Design Pattern. Below are few excellent posts -http://gokubi.com/archives/two-interesting-ways-to-architect-apex-triggershttp://www.embracingthecloud.com/2010/07/08/ASimpleTriggerTemplateForSalesforce.aspxI have learned a lot from the above two posts by Steve Andersen and Mike Leach.But the post by Abhinav Gupta really inspires me a lot and I am going to explain the pattern/template here with few use cases.The motivations for this design pattern are -Write Trigger with minimum codeFollow Salesforce Best Practice – One Trigger per objectFollow another Salesforce Best Practice – Move all code from Trigger to Apex Classes – Handler ClassesAbility to add and order multiple handlers for the same trigger event.Easy to maintain code base.Here is the Apex Trigger template – MyTriggers (Again inspired by Abhinav Gupta)Now using the above template, below is the account trigger handler – AccountTriggerHandlerAnd finally the trigger – AccountTriggerNow the trigger code is very neat and clean. At the same time all our operations against trigger events are moved to handler class.So now let’s consider few use cases -Use Case 1 -While inserting new accounts, if the Account Rating is marked as ‘Hot’, then mark those accounts as Active and make the Customer Priority as ‘Medium’.Implementation -To implement the above requirement, what we need to do is simply add the functionality in AccountTriggerHandler.AccountBeforeInsertHandler class. No changes in Apex trigger code is required.Here is the updated AccountTriggerHandlerUse...

Implementing Decorator Design Pattern in Apex

by Sudipta Deb | Jun 29, 2015 | Apex, Decorator Design Pattern, design pattern, dev 501, use case | 0

This post is part of the series – Design Pattern in ApexI am sure as a developer, we all faced some situations where we need to have some kind of temporary fields just for calculation or displaying in the UI, but we don’t want to store that information in the database or more specific in object. To solve this type of problems, we have Decorator Design Pattern, which allows a user to add a new functionality to an existing object without modifying it’s internal structure. This pattern create a decorator class which wraps the original class and provides additional functionalities keeping class method signature same.Where I should use this design pattern?Below are few user cases, where we can use this design pattern -Say in a table, we are displaying a list of records and want to perform some operations on selected records. We can perform the same operation on each record, but from user interaction point of view, if we can provide some check-boxes so that user can select multiple records inside the table and perform the same operation on all the selected records. We can display check-box against each row, but that check-box information we will not store into the object level, these are only for Visual Force pages.Say when we are creating new accountss we are passing the same account information to some MDM (Master Data Management) system via integration. Once the...

Implementing Strategy Design Pattern in Apex

by Sudipta Deb | Jun 16, 2015 | Apex, design pattern, dev 501, strategy, use case | 0

This post is part of the series – Design Pattern in ApexThe strategy design pattern is the one which allows an algorithm’s behavior to be chosen at run time. It is used to define a set of algorithms to solve a common problem. It allows unique logic per algorithm via encapsulations, but ensures that all algorithms are interchangeable at run time. Here the abstraction is achieved by an interface, whereas individual implementations are done at derived classes. So basically it looks like -Where I should use this design pattern?This design pattern should be used when you are planning to perform an operation that has a common end goal, but there can be different approaches/ways to achieve that goal. All these approaches can be chosen by client at run-time.Let me tell you few real-life Salesforce based example where this design pattern can be used -Let’s say in the account detail page, you want to display the current temperature of the city where the office located. Now based on the country/state, you may need to collect the temperature information from different websites, but your final goal is always the same i.e. showing the temperature.Let’s say you are calculating discounts per product based on month. Every month, the discount amount is getting calculated by different complex algorithms/formulas. Here also, your final goal is same i.e. calculating the discounts.Let’s say you want to set...

Implementing Singleton Design Pattern in Apex – Use Case III

by Sudipta Deb | Jun 5, 2015 | 501, Apex, design pattern, dev 501, singleton, use case | 0

This post is part of the series – Design Pattern in ApexToday in this post I will explain how Singleton Design Pattern can be used to call global describe only once.Requirement -When someone inserts an account record, you need to inspect all the fields in the account object.Implementation -Below is the trigger to start with -MyAccountTrigger-AccountHelper -The problem with this approach is that when someone enters huge number of accounts with dataloader, this code will work like -For each insert, it will create a new instance of AccountHelper which in turn will execute GlobalDescribe(). Very soon we will be hit by LimitException.To avoid that, we have to implement Singleton Design Pattern and below are the changes we need to do that -AccountHelper -MyAccountTrigger-Now you can see for a single transaction, we are calling GlobalDescribe only once because we are now not instantiating AccountHelper object for each Account insert, rather we are only instantiating one AccountHelper object per transaction.Hope you understood the usages of Singleton Design Pattern. If you have implemented this design pattern in any other situation, requesting you to share here. Thanks for your feedback....

Implementing Singleton Design Pattern in Apex – Use Case II

by Sudipta Deb | Jun 4, 2015 | 501, Apex, design pattern, dev 501, singleton, use case | 0

This post is part of the series – Design Pattern in ApexToday in this post I will explain how Singleton Design Pattern can be used to stop calling the same trigger twice.Consider the situation – You as a developer, is updating a field in Trigger which in turns calls a workflow and in that workflow action you are again updating some other field from the same object. And to your surprise, the same trigger is getting triggered again. Getting confused, right?Let’s become more specific with the situation.Consider the below object – Airport__cThe requirements are -Req 1: Send an email if the country and type of an airport changed.Req 2: If the country of an airport changed to “India”, change the type to “International”. To achieve the above two requirements, we have implemented -One trigger, which will send the email if the country and type of an airport changed.One workflow, which will change the type to “International” (Workflow action) if the country of an airport changed to “India”.Here is the trigger -The trigger looks really simple. But you know what will happen, when you will change the country of an airport to “India”, you will get two emails. You know why?First email you will get from Line#6. After that, workflow action will change the type of the airport to “International”. Due to this change you will get another email from Line#11.To solve...

Category: design pattern

APEX TRIGGER DESIGN PATTERN

Implementing Decorator Design Pattern in Apex

Implementing Strategy Design Pattern in Apex

Implementing Singleton Design Pattern in Apex – Use Case III

Implementing Singleton Design Pattern in Apex – Use Case II

Recent Posts

Archives

Recent Comments

Find me online