I have a very simple doubt regarding this Interfaces in sales force, Actually what it says is "This class will have a method but the body will be empty. And body for this method will be provided in another class" My doubt is if we are writing a class and method again what is the use of empty method in interface class ?

See this is one interface class

public interface PurchaseOrder {

    Double discount();

this is my class and empty method

Here i'm providing body to that empty method

public class CustomerPurchaseOrder implements PurchaseOrder {
    public Double discount() {
        return .05;  // Flat 5% discount

this is my another class where i'm defining class name and same method name and i'm providing body.....how is it different from normal class and method ?

  • 1
    The concepts of interfaces and classes are not unique to salesforce so I suggest you Google until you find explanations that are clear to you.
    – Keith C
    Feb 21 '14 at 18:41

An interface is an API "contract." It allows developers to write code that can accept any type of data that implements a particular interface without depending on inheritance. It guarantees that a class has a particular method or set of methods that can be evaluated generically.

One such standard interface is known as Comparable, and classes that implement this interface can be sorted using a custom sort algorithm from List.sort. Without this interface, developers would have to write algorithms that accept a list as input and return a sorted list as output, which does not favor code reuse.

Another way to look at interfaces are to consider them as a certain property of disparate objects. For example, airplanes, people, and rivers all make noise, but it wouldn't make sense to say that they inherit from some common base, since they hardly have anything to do with each other except for a common aspect.

Let's take a look at what this might look like:

public interface INoiseMaker {
    void makeNoise();

public class Airplane implements INoiseMaker {
    public void makeNoise() { /* whiny engine noises */ }

public class Person implements INoiseMaker {
    public void makeNoise() { /* scream and shout */ }

public class River implements INoiseMaker {
    public void makeNoise() { /* rushing water noises */ }

From here, we now gain the benefit of being able to generate noises for each of the three types of objects, without having to concern ourselves with details:

INoiseMaker[] listOfNoiseMakers = new INoiseMaker[] { new Airplane(), new Person(), new River() };
for(INoiseMaker maker: listOfNoiseMakers) {

This discord thankfully can't play, because Apex Code doesn't actually support audio, but here lies the proof of concept: three radically different objects that share a common ability can be activated by generic code.

Interfaces can even be used to allow code that wasn't originally designed with the original code to interact with it. For example, managed packages don't have an easy way to invoke a function from unmanaged code, but if that unmanaged code implements a managed package interface, it can then be called by the managed package.

For example, consider the following interface:

global interface ITriggerValidator {
    void validate();

And, within the managed package, we have something like this:

trigger LeadValidation on Lead (before insert, before update) {
    try {
    } catch(exception e) { /* Couldn't call method validate() */ }

We can now introduce a "hook" that can be used for another developer to call custom validation for leads that runs in the execution context of the managed package (e.g. we could expose additional internal managed data to the method).

  • This is interesting opens up lot of possibilities. Can you explain me what you are doing here in this line (ITriggerValidator) Type.forName( TriggerSettings__c.getValue('LeadTriggerExtension').ClassName__c ).newInstance() ).validate();
    – Prady
    Mar 15 '19 at 12:44
  • @Prady Type.forName returns a class token (commonly called a Type). We use this to create an instance of an Object (in this case, a customer-defined class). (ITriggerValidator) is a cast, where we inform the compiler that the object we're creating implements that interface, and then finally we call the interface method. That little bundle of code packs in quite a few concepts. You may want to to do some research in the documentation.
    – sfdcfox
    Mar 15 '19 at 12:57
  • So you are creating an instance of the class specified in TriggerSettings__c.getValue('LeadTriggerExtension').ClassName__c and .validate is the method in that class?
    – Prady
    Mar 15 '19 at 13:17
  • @Prady yes, that's correct.
    – sfdcfox
    Mar 15 '19 at 13:22
  • makes sense now
    – Prady
    Mar 15 '19 at 13:38

Salesforce interface is java-like interface. You just create interface (kind of full-abstract class) and create methods for this class (they are abstract so they consist only name and kind of returning parameter).

Why do we need interfaces? Benefit of using interfaces is that they provide us unification. When some class implements interface you can be sure that this class contains methods declared in interface. In other words no matter what this class do you can call method declared in interface and be sure that it will for example return type of value declared in interface

check this:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.