views:

1099

answers:

11

Why do we use Interface?

Is it only for Standardization?

+77  A: 

Purposes of Interfaces

  • create loosely coupled software
  • support design by contract (an implementor must provide the entire interface)
  • allow for pluggable software
  • allow different objects to interact easily
  • hide implementation details of classes from each other
  • facilitate reuse of software

Analogy 1: Much like the US space shuttle, Russian Soyuz spacecraft and Chinese Shenzhou 5 can all dock to the International Space Station, because they implement the same docking interface. (This is the just an example - I don't know if it's true in real life however let's suspend our disbelief for the sake of an example)

Analogy 2: Like you can plug various computer monitors into your home computer. You can plug a wall-size TV into it, an old CRT (the thick kind), a 20" flat screen, or a braille machine for the blind to "see" by touch. There's compatibility among these various/different devices and your computer because they all agree on interface standards.

Details of C# interfaces -- With C#/OOP interfaces you're doing the same kind of thing but in the unseen/virtual world.

You're correct about standardization, but also flexibility, scalability, extensibility, maintainability, reusability, testability and power.

(The more you use software interfaces the more these "buzz words" will be understood. And always consider interfaces in the real world because they have done us equally well.)

John K
Very well put...
Frank V
Alan Ridlehoover
@Alan R -testability added. Thanks.
John K
A: 

Not just for that.

But also to make sure that you can reuse code as much as possible. Some of the general actions that can be done in a base class should be implement as such, leaving more specific details to the derived class.

This is an example of how you can use interface:

public interface IObject
{
    double X
        {get;}
    double Y
        {get;}

    public class DrawObject
    {
       public void Draw(IObject object)
       {
          DrawXPoint(object.X);
          DrawYPoint(object.Y);
       }
    }
}

Note that how to draw X and Y are handled in a common class, but how to compute X and Y are handled in different classes.

In this way we can abstract as much common operation as possible out, and leaving on specifics for later implementation.

Ngu Soon Hui
I hope you can't do that with C# interfaces.
kenny
+4  A: 

An interface is used to describe what an implemented thing can do. So you have the possibility to treat several objects which implementing the same interface as a type of this interface.

For example:

public interface IMyInterface{
    public void DoFirst();
    public int DoSecond();
}


public class A : IMyInterface{
   //class have to implement DoFirst and DoSecond
   public void DoFirst(){
     Console.WriteLine("Blubb1");  
   }

   public void DoSecond(){
     Console.WriteLine("Blubb2");
     return 2;  
   }
}

public class B : IMyInterface{
   //class have to implement DoFirst and DoSecond
   public void DoFirst(){
     Console.WriteLine("Blibb1");  
   }

   public void DoSecond(){
     Console.WriteLine("Blibb2");  
     return 4;
   }
}

The classes implement the Interface in several ways. But you can use them as IMyInterface. For example:

public static void DoMethodsInInterface(IMyInterface inter){
    inter.DoFirst();
    inter.DoSecond();
}


public static void main(){

   DoMethodsInInterface(new A());
   DoMethodsInInterface(new B());
   //Or use it in a List
   List<IMyInterface> interlist = new List<IMyInterface>();
   interlist.Add(new A());
   interlist.Add(new B());
   foreach(IMyInterface inter in interlist){
      inter.DoFirst();
   }

}

I hope this makes a bit clear why interfaces are useful.

martin
A: 

The main reason the interfaces are used in languages like C#/Java is because those languages don't support multiple (class) inheritance (see http://stackoverflow.com/questions/225929/what-is-the-exact-problem-with-multiple-inheritance).

But multiple (interface) implementation is permited allowing classes to be used in diferent ways.

Catalin DICU
Interfaces in managed languages are NOT a replacement for multiple inheritance. And, even in languages that support multiple inheritance, the concept of an interface sans implementation is relavant and useful. (See dependency injection.)
Alan Ridlehoover
-1 not very well thought-out, or do you really not understand C# or Java?
John Saunders
Catalin DICU
+1 This is essentially what has been discovered the hard way by the experience of C# and Java. If you try to simplify by avoiding multiple inheritance, you just create complexity elsewhere. Due to the lack of a unifying underlying approach, you end up with worse complexity. See Krzystof Cwalina's annotation in *C# Programming Language 3rd Edition*, 1.9 Interfaces, which says exactly this. As of now, there are still unsolved problems in C# and Java that would have simple solutions if multiple inheritance of classes was allowed.
Daniel Earwicker
-1 inheritance and interfaces are really very different.
kenny
Catalin: I suggest re-wording your answer. :)
Arafangion
A: 

Why do we use interfaces?

Some languages implement polymorphic method calls using vtables and discard most of the type information making it hard not to define interfaces.

So sometime we simply use interfaces because the language design requires it.

Alexandre Jasmin
A: 

Here's the high level view...

Interfaces play a big role in the concept of Information Hiding.

They basically help you hide the implementation details of your class so that a calling class does has no dependency on that implementation. Therefore, by using interfaces you can modify the implementation without changing the calling class. This all in turns limits the complexity of your code and make it easier to maintain in the long run.

When I first started understanding interfaces they were explained to me as a "contract that provides a description your class." Not sure if that will help you but if you think of an interface for a car you could say that it drives, breaks, and turns. So as long as it gets me from point A to point B, I don't really have to know how those functions are implemented.

matt_dev
A: 

Accepted answer is TOP stuff and it's refreshing to see the concept not discarded as most framework design guidelines materials fail to explain or understand it.

Just adding that if you are using Generics seriously, I don't know how you ever got by without them.

rama-jka toti
+1  A: 

Interfaces are somewhat awkward. They support design by contract just by believing, that same name and implemented interface means the same behaviour. This works only thanks to API documentation, it has to be human-checked. That makes interfaces too weak. One way to get around that could be formal specs. On the other hand, interfaces are too strong, too strict. You cannot evolve interfaces which often gets in the way of reuse. This is solved by protocols - mechanism in dynamic languages, which send messages(call methods) and when that message is not supported by receiver, standard callback gets called. Having concrete protocols with constraints would be imho better.

Gabriel Ščerbák
A: 

Think remoting...

There is a client and a server involved here. Lets say they are physically separated by the internet. The client is calling a method whose actual execution happens on the server. From the client's perspective the client doesn't know anything about the object in the server which performs the execution. However it knows what method to call. Because while building the client program, we are only exposed to an interface (or contract). We are not exposed to the whole object which is actually living on the server. Try doing some demo apps in .net remoting, and you'll figure the rest. Happy programming.

deostroll
A: 

By starting with an interface, you can implement a proxy, thus allowing for lazy loading or performing some verifications when calling the methods of a concrete implementation.

lmsasu
+1  A: 

It's for interfacing :), so that you could interface between stuff, it's useful when you have

  • multiple implementations of same stuff
  • when you apply an interface to multiple different classes because you need some sort of convention that these classes are goonna be able to do some stuff or have some functionality
Omu