Why do we use Interface?
Is it only for Standardization?
Why do we use Interface?
Is it only for Standardization?
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.)
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.
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.
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.
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.
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.
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.
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.
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.
It's for interfacing :), so that you could interface between stuff, it's useful when you have