Simplify Testing With the Singleton Pattern
By: Randi Wilson
Tags: Engineering, Salesforce Development, Apex, Singleton Pattern, Design Patterns

While you may be familiar with the technical offerings of Salesforce.com, you might not know much about Salesforce.org, the social impact center at Salesforce. We build solutions that utilize the Salesforce Platform, working to empower organizations in the non-profit and education sectors to achieve their missions by unlocking the power of Salesforce CRM.

We’re also the largest Salesforce ISV (independent software vendor; though not quite as independent as we used to be!). We ship profiles, packages, and permission sets (not to mention lots and lots of Apex!). We strive to work on the cutting edge of the Salesforce platform, working with the latest releases of Lightning Web Components and Apex improvements available to us. Salesforce developers don’t showcase design patterns as much as developers in other ecosystems do, but we work with them all the time at Salesforce.org. I’d like to talk about one of my team’s favorite patterns today.

Who is this for?

If you hold a traditional computer science degree, you’re probably well-versed in design patterns and can skip ahead to the nitty-gritty technical details. However, Apex developers aren’t always traditional engineers; plenty of successful developers I know in the Salesforce ecosystem began their coding journey as Salesforce administrators and have picked up development skills in Apex; others have skipped the four-year degree entirely!

I’m also a non-traditional, self-taught developer. I got my technical bonafides through a development bootcamp. The course that I took alluded to the existence of design patterns, but our instructors told us that we wouldn’t have to worry about that until much later in our careers (and they were right!). I’m several years in as a developer now, and I can tell you that design patterns have a place in all modern coding languages, including Apex. (Examples will be provided in Apex, but the principles can apply to other OOP languages.)

So what are design patterns?

A design pattern is a reusable form of a solution to a design problem.

But what does that mean, exactly?

That’s a fancy way of saying that a pattern is a familiar way of solving well-known problems quickly. They can create shared understanding without digging into technical details, and their benefits and drawbacks can be found in numerous books and articles on patterns.

However, patterns can be difficult to maintain and can become more rigid than a simpler solution would have been. If you don’t recognize the pattern (and there are lots of patterns out there!), you can create unnecessary complexity and confusion amongst the team.

For example, if we’re all going out to eat and I say “Let’s go get pizza!,” that’s a lot faster and easier than saying “Let’s go get that wheat-based, cheese and red-sauce covered baked food! You know, the round one!²”

But if I say “Let’s go get penne alla vodka!”, not everyone is going to know what I’m talking about. Some of you might think we’re going out for drinks, others might think I don’t know good Italian food, and some of y’all might be excited that we’re going out for this super specific and tasty pasta dish. It would just be easier to say “let’s go for pasta”, and we’ll figure out the rest when we get there.

In the words of Erich Gamma, one of the authors of the original Design Patterns: Elements of Reusable Object-Oriented Software (aka the Gang of Four): “A design pattern should only be applied when the flexibility it affords is actually needed.” Before we consider using a design pattern, we should be sure that it fits our needs, and that everyone who will be working with it understands it well.

Singleton Pattern

One pattern that I work with every day is the Singleton Pattern. It’s known as one of the foundational patterns, since it was defined in the original Design Patterns book. The Singleton is a creational pattern, which means that it’s used to define the creation of objects.

The Singleton pattern ensures that only one instance of a class exists and there is a global point of access to it.

Clear as mud right? Let’s break it down.

Image credit: Wikipedia

Singleton as a Railroad Switch

I like to think of the Singleton as a railroad switch.

A switch is what determines which direction a train will go when it reaches a possible alternative path. The normal path will allow the train to continue straight ahead. If the switch is pulled, then the train will take the other path. The tracks and the train only respond to what the switch tells them to do!

Let’s add apply this to a simple model:

Example A: Simple Model, where the switch isn’t pulled

Here we have a controller class, which in Apex would be called by an Aura or Lightning Web Component client. The controller calls the instance of the “First Class”, which is where our Singleton Pattern is used (we’ll see how to set that up down below!). Execution continues to a second class, and possibly further down the line until it finishes its job.

Example B: Simple Model, the switch IS pulled

When the switch is pulled (Example B), our code flow will be diverted into the Stubbed class. Think of that alternate path in the photo above; the journey ends here where the Stub lets you arrive early to the station!