Design patterns and Apex

Apex is a proprietary programming language for Salesforce and, therefore, is different from other programming languages, such as Java, C#, and C. Even though the syntax of Apex resembles to Java and C#; however, programming on the Force.com platform is quite different. We will discuss many standard design patterns in the next section of this chapter; however, every pattern may not be suitable for Apex.

A few important differences between Apex and other Object-Oriented Programming (OOP) languages are as follows:

• Apex runs on the multi-tenant platform; therefore, in order to make sure that other tenants are not impacted, Salesforce enforces various limits. As developers, we need to make sure that our code does not breach any governor limits.
• Other programming languages do not mandate code coverage for deployments. However, in the case of Salesforce, the Apex code needs to have a minimum code coverage of 75% (the entire code in the environment) for production deployments.
• Static variables in Java persist until the Java Virtual Machine (JVM) execution lifespan, which may last from days to months or even years. In the case of Apex, a static variable lasts for the duration of an individual user request execution only (until the time the user request is being processed on a server).

Note

Governor limits are Salesforce's way to force programmers to write efficient code. As Apex runs in a multitenant environment, a strict enforcement of all limits becomes a necessity for the Apex runtime engine so that no code monopolizes the shared resources. If because of a bad design or nonrecommended architecture, any code does not comply with governor limits, the Apex runtime throws a runtime exception, which cannot be handled within Apex. Apex also exposes many limit methods to check the limit consumption. Read more about this in detail at  https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.