Why do we use C# interface?

By | August 23, 2015

Why do we use C# interface?

In this article I would not cover anything about C# interface. I have already covered about existence of interface in C# and what are interfaces. As soon as we learn about C# interface, we think that it was very easy to understand about the interface and now at least I have understood a very important concept of C#. But there are different sets of concepts which makes interface so useful. Let’s understand them.

Become an Expert in Programming and Web Development.View all courses!

But as soon as someone asks where should I interfaces, we start doubting on our knowledge about the interfaces and the only example we can give is that C# doesn’t support multiple inheritance that is why we use interfaces. As long as we are not sure why do we use interfaces in C#, our knowledge about them is incomplete.

You may also be interested in below articles:

I have developed a small application here which would help us to understand about the utilization of interfaces.

Project Task: Client would use here Driver(class) to drive a Car(class)

Concepts covered: Following are the concepts which we would cover in this application which in turn would help us to understand about interfaces in C#. Or rather I would say C# interface can be used to achieve following apart from multiple inheritance

  1. Extensibility
  2. Implementation Hiding
  3. Accessing object through interfaces
  4. Loose Coupling.

Before stating the discussion about the code, I would like to take you through the various components of the project as shown in the following figure


C# interface

interface in C#


InterfaceUtilization is the client which would be using the interface components to achieve the functionality for the task. The client only contains the references for the Interfaces and Factory namespaces.

Car and Driver are the assemblies which contains  the classes which implements the ICar and IDriver interfaces from the Interfaces namespace. These classes are the entities whose instances would be used to achieve the desired functionality.

Interfaces is the namespace which contains the contracts or interfaces which would be in turn be implemented by the individual classes(in our class Car and Driver).

Factory is the assembly which is used by the client(InterfaceUtilization) to create and return the instances of the entities (Car and Driver). Factory has the references of the Car, Driver as well as the Interfaces namespaces.

Now I would like to discuss all the points here one by one which I have noted down earlier

  1. Extensibility- We can achieve extensibility using the C# interface. In this example I have two interface ICar and IDriver which are implemented by NormalCar, RaceCar and Driver, RaceDriver respectively. We can easily extend the interfaces to create new classes which implement the same contract functionalities. Suppose if I want to add a new car type apart from which are shown in the above figure as shown below

    And to get a instance of this car type I have to add a new factory method in the factory class as shown below

    now to use this newly created car type in client we just have to call the above method of factory as shown below,

    From the above example we can see that we easily extend a particular interface without having much trouble as out interface already contains the necessary data member and member functions which are need for a particular type.
  2. Implementation Hiding – Our client code doesn’t know anything about the implementation details of both the Driver class as well as Car class, by this we can see that the implementation are known to the client. Here factory class takes care of creating instances of the classes for the client.
    That is why if the client knows only about the C# Interface and Factory namespaces.
  3. Accessing object through interfaces- If we are using classes derived from the interface, in that case there is no need for us to create the instance of the class for which the interface is implemented. We can create variables of the particular interface type which in turn will contain the reference of the type which implements that particular interface. And this variable of interface type can be used as parameter and that particular function can use that reference to achieve its functionality. As we can see in the below mentioned example, I have a function of VintageCar which expects parameter of type IDriver interface and in turn used this variable to work on the class reference.

    This feature helps us to treat different classes as same type of interface. It means that I can create variable of any type implementing IDriver and pass as argument to DriveCar method.
  4. Loose Coupling – As mentioned in the previous point that only an interface type variable can be used to pass as argument which is again helpful to achieve loose coupling. Before explaining this concept please have a look at the code snippet below.

    What we can derive from the above code snippet is that any class which would be implementing C# interface ICar would be having a definition of DriveCar method which takes IDriver as parameter, now having an interface type as parameter gives us flexibility to provide the argument of class instance which derives from IDriver interface for this function . On the other side if the parameter would have been any class type variable it would have been difficult to achieve this flexibility.

Though the above code can be implemented using much more better designing principles, like better use of Factory Pattern but that was not my main concern to write this article.

Please find the solution code for the blog attached here InterfaceUtilization

  • Kevin McBrearty

    This is a nice introduction to the topic but I think you should have also discussed best practices with interfaces. A common mistake when using interfaces is to make them to specific to the implementation or creating monolithic interfaces. In this case you lose the real value of using interfaces which as you covered is to loosely couple your code. A secondary reason that you have kindof glossed over is that it allows for the code to be more maintainable as requirements change by reducing the likelihood that your code needs to change. This is only truly possible when the interfaces a small and well defined. A common practice when using interfaces is to use the adapter pattern to wrap implementations and extend functionality.

    • Thanks a lot for your suggestions and giving me the direction to learn Adapter pattern. I have never used Adapter pattern but it would be nice to learn it after your suggestion. Thanks a lot again.

  • johnye2e

    ICar vintageCar = Factory.Factory.CreateNormalCar(“Old Toyota”);

    I think you meant:

    ICar vintageCar = Factory.Factory.CreateVintageCar(“Old Toyota”);

    • That was an error from my side. Corrected it. Thanks a lot for pointing it out.

  • Dmitry Bytchenko

    I’d rather hide the details (i.e. CreateVintageCar) in the single factory method implementation:
    all we want is to create an ICar instance, and it’s the factory’s task to find out the best underlying class (Car, VintageCar, Truck, ToyCar etc.); so

    ICar myCar = CarFactory.Create(“Old Toyota”);

    Whenever I want to insist on VintageCar creating I’ll call the constructor implicitly:

    ICar myCar = new CreateVintageCar(“Old Toyota”);

  • Pardon for disagreeing, but I have yet to find an instance where an interface was not better represented as an abstract class.

    • You have every right to disagree but with abstract classes we wont get the surety of implementation.

  • Naresh Dhami

    Good one.