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 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.)
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 has to implement DoFirst and DoSecond
public void DoFirst(){
Console.WriteLine("Blubb1");
}
public int DoSecond(){
Console.WriteLine("Blubb2");
return 2;
}
}
public class B : IMyInterface{
//class has to implement DoFirst and DoSecond
public void DoFirst(){
Console.WriteLine("Blibb1");
}
public int 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.
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.
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.
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.
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.
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
Interface provide prototype modal that just contains declaration of functionality of a specific behavior.
and if u want to implement this behavior into class then u must implement this interface in class then class have this behavior functionality or it can have multiple behavior.