Need of interfaces in c#

Question

What is need of interfaces in c# ? as we are writing abstract method in interfaces. instead of that we can directly implement those methods in class.

Answer 1

You may want to read up on polymorphism.

Answer 2

Interfaces do support implementation, so you cannot supply any default implementations as you can with abstract classes. Additionally, interfaces are not restricted to hierarchies, so they are more flexible than abstract classes.

Answer 3

You do not need to use interfaces in C#. They are useful and appropriate in some circumstances, but not in all circumstances. A handy rule of thumb that I use is that if, in your project, you only have one class that implements an interface, you do not need that interface.

Note: one possible counter to this rule of thumb is that you may need to write a second implementing class in the future, which may justify the use of the interface. I do not necessarily agree, as I think a considerable amount of time in programming is wasted anticipating future scenarios which never materialize.

Answer 4

For myself, I find a lot of use out of interfaces when I have similar objects but completely different implementations of the same methods.

Additionally, you can implement multiple interfaces but inherit only one abstract class. I find this very useful because my business objects have a better representation.

When writing any N-Tiered application which separates out business logic from the presentation I think you will start to find many uses for interfaces.

Answer 5

Think of Interfaces as contracts.

You create a contract that a class must follow. For example, if our Dog object must have a Walk method, it's defining class must implement this method.

In order to force every dog class (inherited or not) to implement this method, you must make them adhere to a contract i.e assign an interface which specifies that method.

An interface is a construct that enforces particular classes to follow strict rules of implementation.

The reason for this is that you end up with Dog objects (inherited or not) that now, by default, have a Walk method. This means you can pass these objects as parameters, safe in the knowledge that you can call the Walk method on any Dog class (inherited or not) and it will deffinately be implemented.

Answer 6

Interface is needed exactly as described in books: to define a contract between components. They are one of the best ways to expose certain functionality to other modules while preserving encapsulation.

For example:

1) try, without an interface, to expose some piece of functionality implemented in assembly 'A', to assembly 'B', with no actual implementation visible to assembly 'A'.

2) Even worse - if we consider .NET remoting scenarios, where the server must expose certain functionality to the client, while the functionality is implemented and hosted on the server side. In this case an assembly is published to a client, where interfaces for the server-hosted classes are defined.

Answer 7

If you want to write testable code, you will usually need to employ interfaces. When unit testing, you may have ClassA which depends upon ClassB which Depends upon ClassC etc, but you only want to test ClassA. You certainly don't want to create a ClassC to pass to a ClassB just to instantiate ClassA.

In that case, you make ClassA depend upon IClassB (or some more generic name, most likely that does not imply anything about the ClassB implementation) and mock out IClassB in your tests.

It is all about dependency management for me.

Answer 8

You need interfaces when you want to think of a disparate set of classes as all being the same type of object. Say, for example, you have a set of classes that all read their configuration from a file. One way to handle this is to have all the classes implement the appropriate methods to read a configuration from a file. The trouble with this is that then any code that uses those classes and wants to configure them needs to know about all the different classes so that it can use the methods on them.

Another way is to have them all derive from a single base class. That way any code using the classes need only know about the base class -- it can treat any of the derived classes as the base class and use those methods defined in the base class to do the configuration. This isn't so bad, but it has the major drawback -- since C# doesn't support multiple inheritance -- of limiting your inheritance chain. If you want to be able to have the same sort of ability for some of the classes, but not all of them for a different set of behavior, you're stuck implementing it for all of them anyway. Not good.

The last way is to use interfaces to define the behavior. Any class wanting to implement the behavior need only implement the interface. Any class wanting to use the behavior need only know about the interface and can then use any class that implements it. Classes can implement any interface or even multiple interfaces so you have granular "allocation" of behavior among classes. You can still use base classes and inheritance hierarchies to provide the main behavior of a class in a shared way, but the class is also free to implement other interfaces to give itself more behavior and still retain the convenience of classes that use it to know only about the interface.

Answer 9

Interfaces allow implementers to use their own base class. With abstract classes, implementers are forced to use the given base class to implement the interface even if it actually makes more sense for the implementer to use a project-specific base class.

Answer 10

Interfaces are used to define the behaviour/properties of classes without specifying the implementation. If you begin thinking about classes as fulfilling roles rather than just being a bundle of methods and properties then you can begin assigning multiple roles to classes using interfaces - which is not possible using straight inheritance in C# as you can only inherit from a single class. By making clients of the classes depend on the interfaces (roles) rather than the class itself your code will be more loosely coupled and probably better designed.

Another benefit of this is if you are writing unit tests they are more likely to be focussed on behaviour rather than state. Coding against interfaces makes it very easy to make mock/stub implementations for this type of testing.

Not everything will need interfaces - but most things with behaviour probably (i.e. more than just a bundle of data) should have them IMHO as you'll always have two implementations: a real one in your application and one or more fake ones in your tests.

Answer 11

Interface is a contract that defines the signature of the functionality. So if a class is implementing a interface it says to the outer world, that it provides specific behavior.

Example if a class is implementing ‘Idisposable’ interface that means it has a functionality to release unmanaged resources. Now external objects using this class know that it has contract by which it can dispose unused unmanaged objects.

Answer 12

As presented by GoF 1st principle: Program to an interface not an implementation.

This helps in many ways. It's easier to change the implementation, it's easier to make the code testable and so on...

Hopes this helps.