Introduction
Every software developer who has worked on a large project knows that sooner or later it is necessary to refactor the code, either due to changes in the business logic or due to optimization.
A good programmer must not only solve the problem efficiently but also provide a solution whose code is maintainable. To achieve the latter, the best recipe is always to follow good programming practices associated with the development environment.
Salesforce, of course, is not the exception, and here we will see the use of Constants to make our code clearer and more maintainable.
Apex Constants
In Apex, Constants are class members, generally static, whose values can be initialized only once.
public class someApexClass {
static final String DEFAULT_NAME = 'Jhon Doe';
static final String MAX_CONNECTIONS = 5;
}The final keyword denotes this functionality, and as a convention, the name is used in capitalized snake case.
Note that the Constants, after being initialized, do not vary during a transaction, but their values can be easily modified when it is necessary to refactor the logic dependent on it.
Apex Constants Class
Using Constants allows you to change a common element to several methods of a class quickly in one place, but many times we find configurations common to several classes.
A class whose functionality is to provide Constants to other ones allows to quickly change an element common to several classes.
As an example, imagine that you are a Salesforce Developer in a company that uses a status labeled “Designed” in the Opportunity sobject. This status is used in many places in the code, and one day the Scrum Product Owner requests changing the label to “Design Ready”.
Salesforce allows you to rename the status in the sobject configuration and reassign the values of the existing records, but, what about the code? If the old status label is in each different class, we must change it by hand, which forces us to deploy all those classes, and perhaps to forget something in the deployment. If we previously defined a Constant and used it in all these classes, we only need to change the value in one place.
A Word About Performance
As Salesforce Developers, you know that Sharing Is Caring in the Multitenant Cloud, so we work for efficiency.
It is not the intention of this post to explain in detail what a Property is in Apex and its functionalities, but when the Apex Constants Class grows using the syntax that we presented previously (members syntax), the execution time of all the transactions that use any of the Constants of this class grows significantly.
A class with approximately 300 declared Constants can add about a second of execution time to each transaction (Relative to the hardware, but significant).
The solution: declaring Constants as properties cause them to load as they are requested, and not all at once (lazyload).
public class someApexClass {
static final String DEFAULT_NAME { get{ return 'Jhon Doe'; }};
static final String MAX_CONNECTIONS { get{ return 5; }};
}However, this makes requesting the constant more than once slower than the previous way, so if it is used in a heavy cycle, the operation can be more expensive than using members.
As a general rule, it is advisable to use properties (lazyload) when we have a lot of Constants defined in our class, and members otherwise.