What is the advantage of using Interface?

Question

What is the use of using Interface?

I heard that it is used instead of multiple inheritance and data-hiding can also be done with it.

Is there any other advantage, where are the places interface is used, and how can a programmer identify that interface is needed?

What is the difference between explicit interface implementation and implicit interface implementation?

Answer 1

Interfaces are very useful for

• Dependency Injection
• Inversion of Control
• Test Isolation

Answer 2

Most - if not all - things which can be done with interfaces could just as well get done via inheritance. Interfaces can be used to replace a class design using abstract base classes. Which to prefer is mostly a matter of personal experience and taste. (Of course there are people which state very strict rules about when to prefer the one above the other).

And there do frameworks exist (often in conjunction to DI containern) which force you to use interfaces.

Answer 3

An interface is a contract; it's a guarantee that the methods and properties specified will be available. It provides no implementation, which is what makes it different than a class which does provide implementation.

Interfaces are the highest level of abstraction, it provides no implementation details to the consumer.

Interfaces are almost semantically equivalent to pure abstract classes (classes that don't provide any implementation). In c#, vb.net and other languages, classes can have multiple interfaces, but only one base class. So for a specific advantage interfaces have over classes (abstract or otherwise) is that you can implement multiple interfaces, but only inherit from one class.

Answer 4

IN the most basic of terms, we get back to OOP 101:

Inheritance: Object B "is a" type of Object A. Behaviours and methods implemented by Object A are inherited, implementation and all (with some room for Overriding) by Object B.

Interface: Object A and Object B both "Act Like" examples of an abstract object represented by a common interface. James Gaunt uses the example if Ienumerable above. Other examples might be IPrintable, IDisposable, Etc.

For any given class which implements these Interfaces, the implementation is liable to be quite different (Think about how you implment IDisposable in different classes which utilize a dispose method). However, client code does not need to know or care what the actual object's type is - the code can simply access the desired properties and methods through the interface.

Inheritance is often seen as a "magic" answer to a good many coding problems, but is also widely mis-used as a means to avoid wriing more code. I disagree with user492238 that things done with Interfaces can be just as easily done through inheritance. Such an approach will often box you into a corner. And, as Jodrell observes, multiple inheritance is not a feature of .net (and rightfully so, in my opinion).

When you find yourself implementing the same behavior across several (or many) otherwise unrelated classes, consider defining an interface which provides the API for that behavior. You may have several classes: Person, Animal, Building, Etc. All of which may require a method to provide printable output. You may also have a method which accepts IPrintableObject as a parameter. IN this case, you can implement IPrintableObject within any of the classes you need to print, provide the implementation code within each of those objects, and feed them to the client code.

Answer 5

To tackle the implicit/explicit question, let's say that two different interfaces have the same declaration:

interface IBiographicalData

    {
       string LastName
       {
          get;
          set;
       }

    }

    interface ICustomReportData
    {
       string LastName
       {
          get;
          set;
       }
    }

And you have a class implementing both interfaces:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;

    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

Class Person Implicitly implements both interface because you get the same output with the following code:

Person p = new p();
IBiographicalData iBio = (IBiographicalData)p;
ICustomReportData iCr = (ICustomReportData)p;

Console.WriteLine(p.LastName);
Console.WriteLine(iBio.LastName);
Console.WriteLine(iCr.LastName);

However, to explicitly implement, you can modify the Person class like so:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;

    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }

    public string ICustomReportData.LastName
    {
        get { return "Last Name:" + lastName; }
        set { lastName = value; }
    }
}

Now the code:

Console.WriteLine(iCr.LastName);

Will be prefixed with "Last Name:".

http://blogs.msdn.com/b/mhop/archive/2006/12/12/implicit-and-explicit-interface-implementations.aspx

Answer 6

That's probably more a question to more experienced programmers than an answer, but... For most of the time I was working with small team and we were close, knowing each other well. And I was wondering what for interfaces really are. But my last project was with new team and was little bigger. And it was a holly mess. And after some time I came to conclusion: we should use interfaces.

Not as a way to solve any technical issues, but as a kind of design doc, which is in code, which force you to follow this design, which is hard to ignore, which would make cooperation 100 times easier. It's not problem to sit together and came up with interface. And then you can split and implement stuff alone. But if you follow interface, then every other person in team can much more clearly read the class idea.

So, my best guess, is that interfaces is really nice way for arranging cooperation: implement however you want, but no any public interface outside of interfaces, and rewriting interfaces must be done with others involved. Easy way to keep code in order and separating common stuff, and yours only stuff.