Agile

The agile development model is also a type of Incremental model. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross-functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.

Here’s a quick glance at waterfall practices.

• Everything is planned upfront.

• Requirements are collected in detail before implementation.

• Each step must be completed before moving on.

• The outcome is determined at the beginning.

Plan vs Adapt

I got a good example from the salesforce trailhead and let me highlight here. If you’re trying to decide which process works best for you, consider this: If you’re painting a picture, and you’ve decided your colors, your setting, how much time you will spend painting, and what your final image will look like, then you’ve made little room to make changes along the way. That's not to say the picture won’t be a Picasso, but your process isn’t set-up to incorporate new ideas or feedback that can change the final image (for the better, of course). That’s when you might use a waterfall approach.

But when you paint iteratively, you can expect to make changes based on early feedback, new ideas, or even new learnings (those colors clash!) rather than painting in a planned, incremental, order. That’s a more agile approach. 

Here’s a visual of those two painting processes:

Advantages of the Agile model

• Customer satisfaction by early and continuous delivery of valuable software
• Welcome changing requirements, even in late development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted

Disadvantages of the Agile model

• There is a lack of emphasis on necessary designing and documentation.
• In the case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

Definition of Scrum

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.

The Scrum Team:

The Scrum Team consists of a Product Owner (responsible for maximizing the value of the product and the work of the Development Team.), the Development Team, and a Scrum Master.

Scrum Master

The ScrumMaster is like the team mirror. This person keeps everyone accountable for their commitments and calls them out when they’re not executing. They manage the team’s delivery process, including how to inspect and adapt their process and projects. They do all this while coaching the team to excel.

Salesforce ScrumMasters:

• Remove blockers

• Don’t micromanage

• Steer the team from bad habits and inefficient processes

• Enable the team to become collaborative and high-performing

Product owner

The product owner is responsible for what and why of our process. This person works closely with customers to ensure they’re getting a good return on their Salesforce investment. They do this by prioritizing the product backlog and communicating the highest-value work. They’re also responsible for communicating the vision to internal teams by providing them with a prioritized list of work. We call that list a product backlog.

At Salesforce, the product owner:

• Facilitates communication among stakeholders, team members, and the ScrumMaster.

• Defines, prioritizes, and approves work for the team.

• Works with customers to define desired features.

Scrum Team

The team manages its own work and organizes the work to complete the sprint or cycle.

At Salesforce, teams are: 

• Self-organizing and empowered

• Consistently adjusting and updating their process and products based on lessons they’ve learned

• Autonomous

• Accountable individually

• Collaborating on commitments for each sprint

Sprint

In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review. 

Story point

This is used to measure the effort required to implement a story. In simple terms it’s a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large. Mostly commonly used series is the Fibonacci series.

Velocity:

• At the end of each iteration, the team adds up  effort estimates associated with user stories that were completed during that iteration. This total is called velocity.
• Velocity is the delivery capacity of the team per sprint. Typically expressed in Story points(effort to complete the story). 
• Velocity is a powerful method by which we can measure the rate at which scrum development teams consistently deliver business value.  Velocity is the sum of the estimates of delivered features per iteration. "Worked example:" an agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete.

Agile teams generally acknowledge only two levels of completion, 0% done or 100% done. Therefore, C is not counted toward velocity, and velocity as of that iteration is 4 points.

How do I estimate future iterations?

Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.

Product Backlog:

All work items related to a product/project, ordered by a Product Owner. What exactly is a product backlog, and what does it consist of?   

• It’s constantly refined as teams learn new information about the product.

• Higher-priority items have more detail in them so that they’re work-ready.

• It includes not just project-related work, but also support or maintenance work, non-functional requirements, and research.

• The product owner owns it, and it’s their job to prioritize the work items.

Sprint Backlog

• All work committed to and pushed into a Development Teams's upcoming Sprint/iteration as chosen by the Development Team in their Sprint Planning meeting.
• Sprint Backlog is the subset of the Product Backlog.

Definition of Done (DoD)

Here’s a scenario to consider: Imagine there’s a new piece of product functionality that you need to create. You assign this new task to your team and ask them to implement it this month. They do it, and move on. Fast-forward a few months, and the finished work item resurfaces with new problems. Perhaps there are customer complaints because integrations were not fully tested. Maybe security issues were not addressed, or performance was not up to par. The conclusion: The work item wasn’t actually finished, at least not enough to deploy.
Our definition of done is a set of guidelines that dictates everything a team is required to do before they can call the work truly done. Creating a standard for this is critical to upholding one of our core Salesforce values: trust.

• DoD is a subject not object means Team define the DoD. 
• DoD is defined by mutual agreement within the team.
• the Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design
  having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner
• the Definition of Done limits the cost of rework once a feature has been accepted as "done"

Implement Scrum

There are two main types of Scrum meetings at Salesforce.  

1. Planning meetings: These happen at all different stages of the project—drawing it out, it looks like a layered cake. Regardless of what stage the project is in, teams regularly meet to ensure they’re aligned on the final outcome.

2. Inspect and adapt meetings: We’ve talked a lot about how important it is for teams to take new learnings and apply them to the next sprint. This is the time they do this. These meetings are geared toward improving the process and the products.

Planning Meetings

Agile teams then use this to continue their planning. 

Release Planning Every 4 Months

• We release new versions of our core platform every 4 months—and there are smaller updates even more frequently with other products. And we deploy infrastructure releases as needed. At the beginning of every major release cycle, we have a high-level planning meeting to create a roadmap for each cloud. 

• Key purposes of these meeting:

• Provide a high-level understanding of new features and functionality.
• Negotiate schedules and set expectations for delivery.
• Align on business and customer priorities.

Backlog Refinement Planning Happens Every 2 Weeks

• The next step in the planning process is to prepare for the upcoming sprint. Teams plan a couple of sprints ahead, where they review their product backlog to make sure the highest-priority items are ready to be worked on.
• What’s the purpose of these meetings? The team provides input and gets clarity on what is coming down the pipe.
• Work is broken into smaller chunks.
• Conditions of satisfaction are drafted, which help clarify desired outcomes.
• Identify work that is not ready for prime time.

Sprint Planning Happens Every 2 Weeks

• Before the sprint starts, teams get together to create a roadmap of what they intend to accomplish over the next 2 weeks. During this meeting, the team agrees and commits to a work plan. 
• Usually, at these meetings, the teams start with the product backlog, looking at what projects are at the top of the list and decide which they can commit to now. 

Daily Stand-Up Happens (Almost!) Every Day

• Although Scrum calls for daily stand-up meetings, most teams exercise the no-interruption Thursday rule, which is exactly what it sounds like: no meeting on Thursdays.
• What does it look like?
• It’s a very brief sync where team members make sure they are all focused on the right objectives for the day—and offer help where needed.
• The frequency is meant to prevent team members from spinning their wheels and bottlenecking progress.
• It provides visibility on daily progress.

Inspect and Adapt Meetings

1. Retrospective: A Look Back at the End of Every Sprint

• This is the meeting where the team can take responsibility for their progress or failures.
• Each sprint, the team spends a little time analyzing how well they worked or didn’t work. They focus on two things during this review period: process and the team. 
• At this time, the team inspects how they worked during that sprint, and then decides what to change and adapt for the next sprint. The ultimate goal is to improve the process and the deliverable every sprint.  
• It is expected for a team to have a couple of “actionable experiments” after each sprint—something new they can try in the next sprint. These new action items are added to their sprint or Kanban boards, and one person holds the team accountable to those. 

1. Sprint Demo Happens Each Sprint

• During the second of the two inspect and adapt meetings, the team presents finished work to product owners and stakeholders to get feedback and input. They inspect their deliverables, and take what they learned and adapt it to their process moving forward.
• Without these meetings, the team misses out on the opportunity to improve.

Scrum Vs Kanban

Scrum Case Study

Imagine if your team has to create a new website. The team can break down the work into the smaller projects. As the smaller work items are completed, the team can review their progress each sprint and adjust to ensure the whole project is delivered successfully. If the project needs a predictable delivery schedule, Scrum is the preferred workflow to use. 

Kanban Case Study

Does your team have to deal with service outages? That’s an example of interruption-driven work. You can’t always know about or plan for outages 2 weeks in advance. Teams that work on architectural, service, or platform support tend to work on items that just pop up and create shifting priorities.

Triggers

Apex Trigger is an apex script that executes on a specific event. There are the following events:

• Insert
• Update
• Delete
• Undelete
• Upsert
• Merge

Types of triggers

Before triggers

• Before-trigger events occur before a record’s changes are committed to the database.
• This particular event is ideal for performing data validation, setting default values, or performing additional logic and/or calculations.

After triggers

• After-trigger events occur after a record has been committed to the database, which means that records being inserted will have a record id available.
• This particular event is ideal for working with data that is external to the record itself such as referenced objects or creating records based on information from the triggered object. Suppose need to insert the contact whenever an Account is inserted.

Trigger Context Variables

isExecuting:       

• A better name for this flag might be "isCreatedByTrigger".Returns true if the current context for the Apex code is a trigger, not a Visualforce page, a Web service, or an executeanonymous() API call.When decoupling the Apex trigger handler class from the actual trigger, the Apex class has no way to know what context it's called in (unit test, web service, visualforce page, trigger). This flag just means the handler was executed by a trigger.

isInsert:

• Returns true if this trigger was fired due to an insert operation, from the Salesforce user interface, Apex, or the API.

isUpdate:

• Returns true if this trigger was fired due to an update operation, from the Salesforce user interface, Apex, or the API.

isDelete

• Returns true if this trigger was fired due to a delete operation, from the Salesforce user interface, Apex, or the API.

isBefore

• Returns true if this trigger was fired before any record was saved.

isAfter

• Returns true if this trigger was fired after all records were saved.

Trigger.new

• Returns a list of the new versions of the sObject records. Note that this sObject list is only available in insert and update triggers, and the records can only be modified in before triggers.

Trigger.Old

• Returns a list of the old versions of the sObject records. Note that this sObject list is only available in update and delete triggers.

Trigger.newMap

• A map of IDs to the new versions of the sObject records.

Trigger.oldMap

• A map of IDs to the old versions of the sObject records.

 When We cannot write the trigger:

• We cannot write the trigger on object where istriggerable is false like AccountContractRole

Best Practices of writing the trigger:

While trigger the trigger, we should keep following points in mind:

• Try to write one trigger on one object
• Use handler class to write the logic
• Use context variable to filter the records
• Use Map and Set in the trigger
• Minimize the number of SOQL statements by preprocessing records and generating sets, which can be placed in single SOQL statement used with the IN clause.
• Minimize the number of data manipulation language (DML) operations by adding records to collections and performing DML operations against these collection

What is CRM?

CRM( Customer Relationship Management) is used to build a good relationship with the customer.
CRM Model is used to manage the organization's interactions

• Phone calls
• Emails
• Meetings
• Social Media

with Customer and prospects pertaining to Sales, Marketing, support.

Goals of CRM:

• Increase in Sales revenue
• Increase visibility between departments
• Decrease operating costs.
• Streamline business process 

Salsforce API

API stands for Application Programming Interface. With the help of API, we can connect two or more applications altogether. 

To understand the concept of API, let's consider the example of a restaurant. If you go there, you will get a Menu list, and there will be a separate kitchen. You just select the item from the menu list and the waiter will take the order and send it to the chef in the kitchen and once the order is ready, he will deliver to you.  You know need to worry about how the order will come. You just order and you get it from the waiter. Here waiter is working as an API.

There are the following APIs in the Salesforce:

REST API

• Force.com REST API lets you integrate with the force.com applications using simple HTTP methods.
• The request/response would be in the form of xml or JSON.
• Useful in light weighted application like mobile application
• Click for more detail

SOAP API

• SOAP API works on SOAP (WSDL) protocol. 
• The request/response would be in the form of xml.
• We can use SOAP API to integrate Salesforce with your organization’s ERP and finance systems.
• Click for more detail
  

Tooling API

• As the name itself suggests, use tooling API to build custom development tools for Force.com applications.
• You can get the code coverage information with the help of Tooling API.
• Click for more detail

Streaming API

• Use Streaming API to receive notifications for changes to data that match a SOQL query that you define.
• Streaming API is useful when you want notifications to be pushed from the server to the client.
• Streaming API enables you to reduce the number of API calls and improve performance.
• Click for more detail

Chatter REST API

• Access Chatter feeds and social data such as users, groups, followers, and files using REST.
• Click for more detail

Bulk API

• Bulk API is based on REST principles and is optimized for loading or deleting large sets of data.
• You can use it to query, insert, update, upsert, or delete many records asynchronously by submitting batches. Salesforce processes batches in the background.
• SOAP API, in contrast, is optimized for real-time client applications that update a few records at a time. SOAP API can be used for processing many records, but when the data sets contain hundreds of thousands of records, SOAP API is less practical. Bulk API is designed to make it simple to process data from a few thousand to millions of records.
• The easiest way to use Bulk API is to enable it for processing records in Data Loader using CSV files. Using Data Loader avoids the need to write your own client application.
• Click for more details
  

Metadata API

• Use Metadata API to retrieve, deploy, create, update, or delete customization for your organization. 
• The most common use is to migrate changes from a sandbox or testing organization to your production environment. 
• Metadata API is intended for managing customization and for building tools that can manage the metadata model, not the data itself. Like The Force.com Migration Tool, Force.com IDE
• Click for more detail
  

Apex REST API

• Use Apex REST API when you want to expose your Apex classes and methods so that external applications can access your code through REST architecture.
• Apex REST API supports both OAuth 2.0 and Session ID for authorization.
• You can also read this article for the detailed information

Apex SOAP API

• Use Apex SOAP API when you want to expose Apex methods as SOAP Web service APIs so that external applications can access your code through SOAP.
• Click for more detail
  

To know more about the security aspect of integration, pls Click here

Skinny Tables

• A skinny table is a custom table in the Force.com platform that contains a subset of fields from a standard or custom base Salesforce object.
• To enable skinny tables, contact salesforce.com Customer Support.
• The storage consumed by a skinny table does not count toward your org's storage.
• Skinny tables do not expire, and are automatically updated by the system as data is uploaded.
• Skinny tables are created by our DB Performance Engineering team upon analyzing each specific case, if it would improve the performance of reports, list views, or SOQL queries.

Benefits of Using Skinny Tables

• A skinny table is a custom table in the Force.com platform that contains a subset of fields from a standard or custom base Salesforce object. By having narrower rows and less data to scan than the base Salesforce object, skinny tables allow Force.com to return more rows per database fetch, increasing throughput when reading from a large object, as this diagram shows.
• Skinny tables do not include soft-deleted rows (i.e., records in the Recycle Bin with isDeleted = true), which could also reduce the table volume in some cases.
• The Force.com platform automatically synchronizes the rows between the base object and the skinny table, so the data is always kept current

Risks or Limitation Associated with Using Skinny Tables

• They don’t have the dynamic metadata flexibility you find in the base object. If you alter a field type (e.g., change a number field to a text field) the skinny table becomes invalid, and you must contact salesforce.com Customer Support to create a new skinny table.
• Skinny tables can contain a maximum of 100 columns.
• Although data for existing fields in the Skinny table are automatically updated, the skinny table will need to be recreated if a new field has been created.
• They cannot be created on Activities
• There's nothing visible to the customer when a skinny table exists. It's entirely transparent.

Note: While it is important to follow best practices for managing large volumes of data—and to execute archiving-and-purging strategies as much as possible—understanding skinny tables might help you further improve your Force.com performance. If you take proactive measures, clarify skinny tables’ possible effects on end users, and use skinny tables only when appropriate, you can keep your organization fit, smart, and fast.

Refer below Links:

https://help.salesforce.com/apex/HTViewSolution?urlname=Force-com-Query-Optimizer-FAQ

https://developer.salesforce.com/blogs/engineering/2013/03/long-and-short-term-approaches-for-tuning-force-com-performance.html

View State

• View State is useful to maintained the state during Post Backs. 
• As we know GET and Post Request works on HTTP protocol and http protocol is stateless protocol, which means every request and response is treated as independent request for the page. So there should be some mechanism which can be used to mention the state so that we can have the required information for processing the page. View State is the mechanism to maintained the state
• Suppose we input some value in the VF page and submit the result, If any custom validation runs and throw the error to the VF page, the view state mention the old values that we have filled earlier.

Limitation
In this way, View state makes your job as a developer easier by automatically managing state during post-back. However as we know Salesforce is based on multi-tenant environment where more than one user works at a time so it is required to use the View state within the limit.  135 KB is the limit of View State.
Steps to avoid the View State

1. Minimize Number of Forms on a Page
2. Declare variables as Transient if possible.
3. Use Custom Settings to Store Large Quantities of Read-Only Data
4. Declare variable as Static, as it is not saved in View State.
5. Refine your SOQL to only retrieve the data needed by the page.
6. Refactor Your Pages to Make Its View Stateless: (Instead of using apex:commandLink or apex:commandButton components (which need to be inside a apex:form component) to invoke an action, use an apex:outputLink)
7. If you want to manage your own state, instead of using <apex:form> use HTML <form> tag instead.

You can also read this article on Salesforce blog which explains ViewState Mechanism.

Action Components in VF Page

There are following action components in VF page:

• apex:actionSupport
• apex:actionStatus
• apex:actionRegion
• apex:actionPoller
• apex:actionFunction

apex:actionSupport:

• As name itself suggested, actionSupport provide the support to action of the other component.
• Provides support for invoking controller action methods from other Visualforce components.

<apex:page >

<apex:form>

   <apex:pageBlock>

       <apex:sectionHeader title="Rerender Example"/>     

           <apex:commandButton value="Click here!">

               <apex:actionSupport event="onmouseover" rerender="time" status="refreshstatus"/>

           </apex:commandButton>

           <apex:actionStatus id="refreshstatus" startstyle="color:green;"    startText="Refreshing...."></apex:actionStatus> 

           <apex:outputpanel id="time">

               <apex:outputtext value="{!NOW()}"/>

           </apex:outputpanel> 

   </apex:pageBlock>

</apex:form> 

</apex:page>

Explanation 

<apex:actionSupport event="onmouseover" rerender="time" status="refreshstatus"/>

The event attribute determines which action should refresh the page, we have a onmouseover. That's why when you move the mouse over the command button, the time gets refreshed..

The rerender attribute determines the portion of the page to be refreshed. We have "time" which is the ID of the portion to be refreshed....

The actionstatus attribute determines the status message to be displayed when the refresh takes place. We have "refreshstatus" which is the ID of the associated "actionstatus" tag.

apex:actionStatus

• Displays the status of an AJAX update request.
• An AJAX request can either be in progress or complete.
• When some operation is happening in the back ground then it will show processing message to the user so that she/he can wait.
• Refer the above example

apex:actionRegion

• actionRegion provides an area of a Visualforce page that decides and separates which components should be processed by the force.com server when an AJAX request is generated.
• Only the components which are inside actionregion component are processed by server, so it increases visualforce page performance.
• Refer http://www.sfdcpoint.com/salesforce/actionregion-visualforce-salesforce/ blog for the more details

apex:actionPoller

• A timer that sends an AJAX update request to the server according to a time interval that you specify

<apex:page controller="exampleCon">

    <apex:form>

        <apex:outputText value="Watch this counter: {!count}" id="counter"/>

        <apex:actionPoller action="{!incrementCounter}" rerender="counter" interval="15"/>

    </apex:form>

</apex:page>

                   

Apex Code: 

          

public class exampleCon {

    Integer count = 0;

          

    public PageReference incrementCounter() {

        count++;

        return null;

    }

          

    public Integer getCount() {

        return count;

    }

}

apex:actionFunction

• Used to call the action method of the controller from the JavaScript
• An <apex:actionFunction> component must be a child of an <apex:form> component.

Note: 

Rerender is used when you want to refresh only a portion of your visualforce page when the user does some action... This would actually improve the user interface and reduce processing time

Grid in VF page

There are many ways to show the data in the form of gird in the VF pages.

1. apex:dataTable
2. apex:dataList
3. apex:pageBlockTable
4. apex:repeat

apex:dataTable 

• It should be inside of <apex:pageblock> or <apex:pageblocksection>
• <apex:pageblocktable> has a required attribute called "value"
• It uses the standard salesforce page styles
• column headers will be displayed automatically

apex:dataTable

• no need to write inside <apex:pageblock> or <apex:pageblocksection>
• there is no required value
• data can be displayed using custom styles
• we need to specify column headers explicitly

apex:repeat

• there is no proper alignment of data in repeat as compared with datatable
• there is no javascript events like onmouseover,onclick.
• simply data displayed in irregular format

apex:dataList

• An ordered or unordered list of values that is defined by iterating over a set of data.
• It support js event onclick , ondblclick etc

Note: The data set can include up to 1,000 items in all above component. Use Readonly attribute to increase the limit.

Licenses Overview

License provide the specific Salesforce functionality to the user. User must associate with one user license. When creating or editing a Salesforce User, there is a picklist field that lets you assign a specific User License. Profile is dependent on license. To enable additional functionality, you can assign permission set licenses and feature licenses to your users or purchase usage-based entitlements for your organization.

To view a list of the active user licenses in your Salesforce org, click Your Name | Setup | Company Profile | Company Information

 

Salesforce provides the following types of licenses and usage-based entitlements.

1. User License
2. Permission Set License
3. Feature License
4. Usage based entitlement

1. User License:

A user license determines the baseline of features that the user can access. Every user must have exactly one user license.

Salesforce

Salesforce licenses are designed for users who require full access to standard CRM and Force.com AppExchange apps. CRM apps are anything that requires access to Standard Objects like Leads, Opportunities, Forecasts, Cases, and Solutions.

Salesforce Platform

Salesforce Platform licenses are designed for users who only need access to custom apps, and NOT the standard CRM functionality. Salesforce Platform users DO have access to the "core" Salesforce Standard Objects and functionality, like Accounts, Contacts, Reports, Dashboards, Documents, Custom Tabs. Salesforce licenses have much more administrative permissions than Salesforce Platform licenses. If User license is Salesforce, then we can get System Admin as profile.

Chatter Free

Access standard Chatter people, profiles, groups, and files without a Salesforce license at no additional cost.

Chatter External

Allows your clients access to chatter groups at no additional cost.

Communities User Licenses:

There are three Communities licenses for external users: Customer Community, Customer Community Plus, and Partner Community. 

2. Feature Licenses

A feature license entitles a user to access an additional feature that is not included with his or her user license, such as Marketing or Work.com. Users can be assigned any number of feature licenses.

3.Permission Set Licenses

A permission set is a convenient way to assign users specific settings and permissions to use various tools and functions.

4. Usage-based Entitlements Overview

A usage-based entitlement is a limited resource that your organization can use on a periodic basis—such as the allowed number of monthly logins to a Partner Community or the record limit for Data.com list users. 

Apex Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context. With the help of design, we can avoid much error well in advance. Design Patter ensures the best practices of coding.

The following are a list of design patterns in Apex:

1. Singleton
2. Strategy
3. Decorator 
4. Facade
5. Composite
6. Bulk State Transition 

Singleton

• Repeated execution of a class within a single transaction may lead to exceed the governor limit. This pattern is to reduce repeated instantiation of a class.
• Problem: Developers often write inefficient code that can cause repeated instantiate of objects. This can result in inefficient, poorly performing code, and potentially the breaching of governor limits. This most commonly occurs in triggers, as they can operate against a set of records.
• Implementation: In order to implement a Singleton pattern in apex, the class must instantiate only once. It is implemented by:
• Creating a class with a method that creates a new instance of the class if it doesn't already exist.
• If it already exists, then simply return a reference to the object.
• For example, use a global static variable, before assigning it to value check if it has already a value.

Strategy:

• The Strategy pattern (aka the policy pattern) attempts to solve the issue where you need to provide multiple solutions for the same problem so that one can be selected at run-time.
• Use Case: You need to provide a geographical-based search engine solution where the implementing code can choose the search provider at run-time.
• Implementation: In Order to implement a Strategy pattern in apex, you need to define a family algorithms. It is implemented by:

• Creating the interface class with methods that will be implemented by other classes 
• Covers use of interfaces, Aggregation (Has A) relationship, Method Overloading.

Decorator:

• In some scenarios, we need to show the value only in UI level, but not to store that value in Database. Here we have a Decorator Design pattern to solve this kind of problem. This pattern provides the decorator class which wraps the apex class to provide the extended functionality for the sObject
• Use Case: Whenever the user needs to select the records and process the selected records however select checkbox is not saved.
• Implementation: In order to implement a Decorator pattern in apex, we need to aware that this is not a true implementation the intention is to add the behavior at the run time. It is implemented by:
• Use of wrapper classes inside wrapper class and perform required operation when it is get;set; in vf page instead when the page is loading. We can say it lazy loading. Used in VF page mostly. 

Bulk State Transition:

• The bulk state transition requires a trigger that allows only the eligible record that has changed its state and a utility class to implement the logic. The trigger needs to be framed by its events and the DML type. 
• Use Case: Whenever a developer needs to write the trigger we always consider as bulk and we use the Bulk State Transition Pattern.
• Implementation: In order to implement a Bulk State Transition in apex, use proper filter to check the eligible records using the Trigger Context variable and call the utility class which contacts the method that handles the operation on the bulk operation.

Facade – 

• The intention of the facade design pattern is to convert complex Apex classes into simplified classes or interfaces where groups of classes are either wrapped into one class or only one class is used to delegate responsibilities to the other classes.
• Use Case: Simplifying the execution of classes with complex interfaces (e.g. web service callouts)
• Implementation: Maintainability of Apex code by simplifying the execution of one or complex classes with a facade class. For example, just create a simple class where place code to execute methods/functions of a complex class.

Triggers and Order of Execution

When there is any DML on the Salesforce Record, Salesforce perform the following actions in order:

1. Salesforce loads the original values from the database or initialize the new values.

2. Loads the new value from the request and overwrite the old values.

3. System Validation will run. (In case of Opportunity Line Items Custom Validation will also run)

4. Salesforce executes all the before triggers.

5. Custom Validation will run.

6. Records will save to the database but will not commit

7. Executes all after trigger.

8. Assignment Rule

9. Auto Response Rule

8. Workflow rule

9. Escalation rule

10. Commits all the DML to the database.

11. Post Commit Logic such as sending mails.