In this article I would not cover anything about interfaces as I have already covered about existence of interfaces in C# and what are interfaces. As soon as we learn about interfaces, we think that it was so easy to know about the interfaces and now atleast I can understand a very important concept of C#. 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, our knowledge about them is incomplete.
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.
- Extensibility
- Implementation Hiding
- Accessing object through interfaces
- 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
The project to understand interfaces 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
- Extensibility- We can achieve extensible using the interfaces in C#. 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
public class VintageCar:ICar
{
private string modelName;
public VintageCar(string modelName)
{
MoodelName = modelName;
}
#region ICar Members
public string MoodelName
{
get{ return modelName; }
set{ modelName = value; }
}
public void DriveCar(IDriver driver)
{
if (driver.YearsOfExperience > 10)
driver.Drive();
}
#endregion
}
|
And to get a instance of this car type I have to add a new factory method in the factory class as shown below
|
|
public static ICar CreateVintageCar(string modelName)
{
return new VintageCar(modelName);
}
|
now to use this newly created car type in client we just have to call the above method of factory as shown below,
|
|
IDriver myDriver= Factory.Factory.CreateDriver("vikram", 38, 5);
ICar vintageCar = Factory.Factory.CreateNormalCar("Old Toyota");
vintageCar.DriveCar(myDriver);
|
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.
- 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 Interface and Factory namespaces.
- Accessing object through interfaces- If we are using classes derived from the interface, in that case there is no need for use to create the classes instances which. We can create variables of the particular instance 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.
|
|
public void DriveCar(IDriver driver)
{
//years of exprience need to be more to hanle this car type
if (driver.YearsOfExperience > 20)
driver.Drive();
}
|
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.
|
|
IDriver myDriver= Factory.Factory.CreateDriver("vikram", 38, 5);
ICar vintageCar = Factory.Factory.CreateNormalCar("Old Toyota");
vintageCar.DriveCar(myDriver); // prints "Cannot drive this car"
IDriver raceDriver = Factory.Factory.CreateRaceDriver("myname", 40, 20);
vintageCar.DriveCar(raceDriver); // prints "myname is driving a race car";
|
- 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.
|
|
public interface ICar
{
string MoodelName { get; set; }
void DriveCar(IDriver driver);
}
|
What we can derive from the above code snippet is that any class which would be implementing ICar interface 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.
