Here Are Three Apex Patterns Your Salesforce Development Team Should Know

Apex is strong, but with strength comes a lot of duty. Because if you’re not cautious with Apex and custom code in your Salesforce system, you may end up with technical debt. This is especially crucial considering how lengthy some Salesforce orgs may be (decades or more).

I’ve been a Salesforce engineer and builder for over 10 years, so I’ve seen both good and bad code bases. Spending a little time on the layout of your Apex code at the beginning will save you a lot of time later. I talk about three Apex design patterns that your Salesforce workers can easily use and that will have a big effect on the health of your Salesforce code base. It’s not just a matter of theory; it will also lead to less bugs and more releases on time.

Apex Codebase, Code Bloat, and Code Smell

Most of the time, though, I find Apex codebases to be a mess:

I find several triggers for the same item that do different things.

I see copies and pastes of filler code between classes and functions all over the file.

People hard code numbers all over their Apex, like record type IDs, manager email addresses, API urls, and so on.

I have a hard time figuring out what files with names like “qtrReportSumCont4.cls” and “CoTrig_v4_JohnApr19.trigger” are about.

I read old Apex that hasn’t been formatted in decades.

These problems compound and cause code bloat and code smell, which in turn causes errors that your end users will experience and your Salesforce development and admin team will battle to rollback and squash (not to mention teams abandoning procedures and reverting back to doing things on spreadsheets).

But you can set up your Apex software to be flexible and scalable. Now I’ll talk about the three Apex design styles that your Salesforce devs can easily use.

Version Control and a Code Style Guide are needed.

Before we can start, I need to know if you are using a source control system like GitHub or a tool made for Salesforce like Blue Canvas. If you aren’t keeping track of Apex in a Git repository, do that first. While common options like GitHub are fine, Salesforce-specific solutions like Blue Canvas make integrating DevOps and Git a breeze.

For these design patterns to be used, you need source control because you need to be able to review code to make sure the team is following best practises. Also, you can’t see your code very well if you don’t have version control. You won’t know what’s going on if you don’t have that background and awareness. So, please start with this. Once that is done, you can use the designs below.

1. Apex Trigger Patterns

There are numerous ways to think about how Apex triggers should be set up, but most people agree on a few things:

Only build one trigger per object. Having more than one trigger makes it hard to control the order of processing and wastes time.

For atomic unit testing, it is essential that business logic not be included in triggers.

There are too many Apex triggers for too many teams. A simple rule like “one trigger per object” will help you organise your org a lot.

Keeping your real business logic out of your triggers is a bit trickier. If you don’t do this, it will be hard to divide your unit tests for each piece of code into smaller parts. The trigger handler method can be used to create so-called “logic-less” events. The main value of this design is that it can be tested atomically. It also makes your coding clearer because you can organise your trigger filtering logic by specific trigger events (like before delete, after edit, etc.). Having a different way for each trigger event makes it much easier to fix and understand.

2. Service Classes in Apex

Once you understand how it works, this style is pretty easy to use. As a starting point, you can check out this Trailhead: Badge for Service Layer. Each object in Salesforce has its own service class, such as “LeadService.cls” or “AccountSerivce.cls.” You can add static methods to each class that do different things for business logic. The goal is for the service ways to be as useful as possible. Make sure they are simple and DRY!

3. Apex Helper and Utility Classes

While a service class focuses on a single standard or unique object, helper and utility classes focus on useful areas that may touch multiple objects. One good example is the “DateTimeHelper” for changing dates and times. Or “ApiHelpers,” which can help read API calls and replies. The main difference is that service classes are for reuse code for Salesforce objects, while helper or utility classes are for models that don’t depend on a single class.

Some important things to remember:

Each class should be unique instead of being a general one. Instead of “MiscHelpers,” you should think “APIHelpers.”

Keep track of your helpers in one place and make sure it’s up to date. Make “adding documentation” part of your code review process or a human step in your release request.

Include teaching and onboarding for new workers on your helper and utility classes. If they know up front where they can reuse code, this will save them a lot of trouble in the future. This can also be emphasised during reviews of the code.

Summary

These three trends will go a long way towards helping you keep your Apex code well-structured and easy to manage. They will work to reduce bugs and speed up the delivery of new features and functions. But it takes time to put them into action. Investing in method and tools takes time. This is only the beginning. I suggest Trailhead and how to set up an Apex code style guide and IDE tools if you want to learn more.