Salesforce Ninja: An Elite Blog about Salesforce.com

A few days ago I was speaking to a developer friend, he was asked about a Singleton design pattern and he had no idea about. He spoke about how we developers never talk about patterns. And that time it hit me, we developers do not talk about design patterns and algorithms. There are many design patterns available off the shelf, they talk in detail about the problems they can solve. However, in my experience, I have come across and used the following 1. Singleton This is one of the most common and important design pattern to be used. When initiating objects, we need to make sure only one instance of the object is initiated. In a multi-tenant system like Salesforce, it becomes imperative that we do not hog more resources than needed Lets look at an example trigger AccountTrigger on Account (before insert, before update) { for(Account record : Trigger.new){ AccountMasterRecordType rt = new AccountMasterRecordType (); .... } } public class AccountMaster

“Y ou have to be burning with an idea, or a problem, or a wrong that you want to right. If you’re not passionate enough from the start, you’ll never stick it out.” — Steve Jobs Just like the paintings of Jackson Pollock, a Salesforce Developer is an abstract concept. Therefore, it is prudent for me to confirm the audience for this post. To put it very simply, if you write code, this is for you. If you do clicks and not code, this article will mean nothing to you. With that out of the way, let's dig in. Salesforce is one of the hottest skills on the market and more and more people are moving towards the technology. It is wonderful to see new batch of developers, engineers getting into salesforce. In the last six months, I came across two instances, the first one, they had a lot of redundant code and the system was sluggish, slow and governor limits were flying off the charts. The second one had given up. They spun a brand new environment and we redoing the whole thing. Both