Why do we use interface references to call methods of an object?

Question

4.00/5 (1 vote)

See more:

Why do we use interface references to call methods of an object?

For example:

C#

interface abc
{
  void xyz();
}
interface def
{
  void pqr();
}

C#

class Program : Iabc, Idef
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello interfaces");
        Program refProgram = new Program();
        Iabc refiabc = refProgram;
        refiabc.xyz();
        Idef refidef = refProgram;
        refidef.pqr();
        Console.ReadLine();
    }
    public void pqr()
    {
        Console.WriteLine("In pqr");
    }
    public void xyz()
    {
        Console.WriteLine("In xyz");
    }
}

The interface reference refiabc is pointing to the refProgram reference which is pointing to the Program object. refiabc then calls xyz()

Why do we do this (use interface references that point to a central reference that points to an object) instead of calling methods directly by making an instance of a class then calling its methods?

Example:

Why do this:

C#

Program refProgram = new Program();
        Iabc refiabc = refProgram;
        refiabc.xyz();

Instead of just doing this:

C#

Program refProgram = new Program();
refProgram.xyz();

Posted 15-Aug-14 21:03pm

DecompileCodex

Add a Solution

2 solutions

Solution 1

Interfaces are a contract, they don't create anything concrete - they just let you become a "member of the club" - it is up to you to implement the functions that the contract requires, just as in the real world it is up to you to observer the dress code that a club requires and ensure that you pay your membership subscription on time.

For example, if you implement IEnumerable, you join the "club" of classes that can be used in a foreach loop. If you implement IEnumerable<T>>then you can use Linq queries and methods.

Using the interface type instead of the "real" type allows us to write code that is more flexible: If you write a method which works with the interface type, then you can pass it any class which implements the interface because the method doesn't care about what else teh class is r does - it only needs to work with the interface related parts.

Posted 15-Aug-14 21:43pm

OriginalGriff

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-08-15T21:56:00

Of course we can call those methods directly, but only if these methods are accessible via the reference to the class instance. The methods implementing interfaces don't have to be public, they can be explicit implementation method:

C#

interface MyInterface {
   void MyMethod();
}

class MyClass : MyInterface {
    // this method cannot be called using the reference to MyClass:
    void MyInterface.MyMethod(); 
}

You might ask: why doing such things at all, why not implementing interfaces implicitly in all cases, using public methods? I'll answer: because it would allow you to do what you want, directly calling interface implementation methods, through the reference to the instance of implementing class. That's why, in most cases, explicit implementation shown above is better.

Are you surprised? I am telling you that the real benefit is not to allow you to do what you want! That's right. What you want is possible, but this is bad, not always, but in most cases. This is bad because it would defeat the purpose of the interfaces.

The interface is a powerful abstraction device which helps you to isolate some contract from its implementation. You should understand that the runtime type of a variable/member can be not the same as the compile-time type. Interface types can be compile-time types only, but they can never be a runtime-types of any objects; if you will, they are always abstract, the same way as abstract types. This is the base of OOP, late binding and polymorphism. You use the common contract with different implementations of that contract, abstracting from the implementation. And whole idea of programming is all about abstraction.

A very non-trivial point here is: interfaces provides "stronger polymorphism" than base classes. This is because a structure (a value type!) can also implement interface, not only a class, and because interfaces can use polymorphism, so the same object can participate in two or more different polymorphic sets, throw two or more different interface references. With classes, these possibilities are totally lost. Your idea to call interface methods directly means loosing all benefits of interfaces.

Please see my past answers:
Doubts on Interfaces[^],
POLYMORPHISM WITHOUT OVERLOADING AND OVERRRIDING IS POSSIBLE[^],
Interfaces and Polymorphism[^],
How to decide to choose Abstract class or an Interface[^],
Difference between abstract class and interface if they have same no of methods and var[^],
When we use abstract and when we use interface...?[^].

—SA