Possible Duplicate:
How will I know when to create an interface?
I'm wondering about the point of using an Interface.
Do you use Interfaces? If so, when do you decide to use them and when do you decide NOT to use them?
I've currently got interfaces defined for my service layers and my repository layers, but I'm wondering if I'm missing out on other places where they'd be useful.
I guess I just don't fully understand their purpose.
An interface is like a list of rules. You designate the requirements of a class, and for any class that implements this interface, you know that they will follow these rules. You can cast those classes as this interface type, and operate on them knowing that they have the methods, properties, and events that you decided are required.
Some important interfaces in ASP.Net are:
I created my own interface recently when I wanted to be sure all of the classes that were used for a specific purpose have a specific method and event. Knowing that, I could first check that it implements the interface by casting it and verifying:
IMyInterface myinterface = myclass as IMyInterface;
if (myinterface == null)
{
//did NOT implement the interface
}
else
{
//did implement the interface
//call the method we KNOW is there.
myinterface.MyMethod(myparemeter);
}
An interfaces defines a contract. Any class that implements an interface has to fulfil that contract. This means that the class must implement methods defined in the interface.
An interface basically says "I'm defining something that all implementers must do. I don't care how you do it, but you must support these operations that I've specified".
Another use of interfaces is that you can use them in method signatures or type definitions to specify the most generic type of an object. For example, in Java Map is an interface that is implemented by other classes like HashMap or LinkedHashMap. Both HashMap and LinkedHashMap are essentially of type Map. They implement the same methods, but they do things differently (LinkedHashMap preserves insertion-order).
Consider the situation where you have a method that accepts maps. If you didn't have interfaces, you would need to specify a method for each type of map. Indeed, you could do that via overloaded methods, but that approach is not very good. The better way is to specify the type of the method argument as Map. Then, any class that implements Map can be passed in to the method. This way, you don't have to specify a method for each type of map, and also you are not restricting the person who uses your method, to specific implementations of the map.
An interface also guarantees that the specified functionality is present in implementing classes. As such, it also provides a standard way to access that functionality. Interfaces are also useful when you are designing an API (that way you can specify a standard interface to the things you want to expose).
Another benefit of interfaces is that it makes refactoring easy. Let's say that you want to switch out an implementation of a some sort of object. The object might be a method argument or it may be a class property. Since you've typed that argument or object as an interface, you can simply create a new class that implements the interface and pass that class instead. Since you used the interface, you didn't make an extra assumptions as to the details of the class. The interface abstracts out the implementation details of the class that you're using. That way you don't end up making assumptions that makes your code too tightly-coupled to a specific implementation.
To sum it up, interfaces are about abstraction and contracts. With abstraction you hide the underlying details and expose only the bare minimum that you need to expose. That way the person who uses your class or interface is not burdened with the implementation details. All that information is neatly hidden inside the specific class that implements the interface. The contract ensures standardization across the board; a person who uses the interface is sure that all classes that implement the interface expose the same methods.
An interface is for telling others a class does something.
e.g. If you have a SoccerPlayer class which Implements IInjurable - you know from the first line of the class' code, a SoccerPlayer instance knows what to do when injured (you probably knew that just after the hyphen).
Now consider what implementing IEnumerable , IQueryable or IDisposable tells you about an object, and that's without knowing anything about the implementation itself..
Seems like a lot..
One point many other answers miss is that interfaces allow for a very limited form of multiple inheritance, in that two or more unrelated classes can implement a common interface, and code can accept objects which implement that interface without regard for anything else about their type. Otherwise, the only way for code to accept multiple types of objects and exploit any common functionality would be for them to all descend from a common base type which itself implemented such functionality.
As others have said an interface defines a contract that can be implemented by classes and structs. This allows Interfaces like object inheritance to enable polymorphism.
However implmenting an interface differs from inheriting from an object in that
So in general interfaces are good if you want polymorphism and you want it for
Standard examples are IDisposable, IComparable and IEnumerable and show the most obvious uses.
Some things to avoid are marker interfaces (interfaces without methods) and interfaces that aren't supported. By the system. e.g. You have IPost, BasePost, Question, Answer and Comment, but the system only ever uses BasePost.