This document provides an overview of Apex and how design patterns were used to simplify development. It discusses Apex as the programming language for Salesforce, and how patterns like Strategy, Abstract Factory, Helper/Utility classes were implemented for things like flow execution and data access. Code examples are provided for these patterns to demonstrate their use. The document concludes by recommending daily code reviews to maintain high code quality.
1 of 12
Download to read offline
More Related Content
Apex and design pattern
1. Apex and Design Pattern
Quick introduction on Apex and how we used some
design patterns to simplify our life
2. What is Apex?
- Salesforce OOP language
- Subset of Java
- No import (TrumpScript like), No package
- No Stdin, No Stdout
- Case insensitive
3. Model:
DD ( L ) outside the language ( only point and click interface )
DAO pattern
Salesforce provides object and api to manipulate data in apex
View
Visual force page: Markup language ( JSF like )
Controller
Apex!!!
Idea behind Apex ( from my point of view )
4. Show me the code
Example:
Hello_World.cls
ViewModel_BillingItem.cls
Util_DML.cls
5. Our wonderful code
Strategy Pattern
- We define multiple algorithms
- Let client application decide
the algorithm to be used
based on the Context
7. Our wonderful code
Abstract Factory
- Provide an interface for creating
families of related or dependent
objects without specifying their
concrete classes.
- The client software creates a
concrete implementation of the
abstract factory and then uses
the generic interface of the
factory to create the concrete
objects that are part of the
9. Our wonderful code
Helper Pattern
- Also known as Utility Class
- Sometimes its considered an anti pattern
- Developer often forget to have that method in that helper class
- Some languages offer built-in functionality to introduce this pattern and solve
the forgetting issue
- C# Extension Methods
- Scala Companion Object
11. Daily Code Review
No more than 30 minutes
All team is up to date on the code
Continuous refactoring => Code highly maintainable
Very few dead code
Detect immediately classes poorly tested
Unify coding style. The code seems written by the same person
#3: You cannot develop a complete feature on your machine and deploy on the cloud once it is finished.
#4: The design of the language follows the MVC pattern. They decided to keep the DDL outside of the. It must be made directly through the visual interface that salesforce provide. Internally salesforce provide something like a DAO in order to access and modify the data through the language.
The view cannot be manipulated from apex as well but there is a markup language called visualforce page that allows the developer to do that.
Eventually Apex is the language used to build all the controller functionalities. From the data validation to the flows implementation.