Even though you “could” solve a problem by inheriting, see if there’s another option that doesn’t require you to inherit and compose your object of other helper object instead.
The above statement sounded so sophisticated when I read it first, that I wanted to put it in my blog. Yet there is something deep in my heart that tells me: don’t through away your years of experience and achievements gained by reusing objects through inheritance.
Original Thought
When 2 classes, let’s say Car and Vehicle implemented as follows:
public class Vehicle
public class Vehicle
{
public void Drive()
{
Debug.WriteLine("Vehicle is driving.");
}
}
public class Car : Vehicle
{
public void Drive()
{
Debug.WriteLine("Car is driving.");
}
}
By default the new implemented Drive method in the Car class hides the implementation in vehicle for any reference of Car type. So the following instances are expected:
Vehicle v = new Vehicle();
v.Drive();
// output : Vehicle is driving.
Car c = new Car();
c.Drive();
// output : Car is driving.
But the next one might cause unexpected situations when the construction occurs in a method far from calling the drive method.
Vehicle x = new Car();
x.Drive();
// output : Vehicle is driving.
The output for the last call (Vehicle x) changes to “Car is driving.” when the Drive method in Vehicle is defined as virtual and in the Car defined as override.
Looks like the problem is solved.
But sometime I have a factory class creating some instances for me and I simply declare my variables and request for an instance:
Vehicle x = Factory.GetBMW();
This means that the place I use the instance might have no knowledge of how the instance is created and might not even know how they are implementing the Drive method.
For me, the ideal situation might be when I have a reference to a class of type Vehicle, I like it to drive as Vehicle. And when I want to have a Car that drives as a Car, I will define my reference as a Car.
Vehicle x = Factory.GetBMW();
Car y = Factory.GetBMW();
x.Drive();
y.Drive();
Car y = Factory.GetBMW();
x.Drive();
y.Drive();
I can see that my point might not be important for BMW factory and they would rather to create a Car that drives the same way, no matter who is driving it.
Suggested Solution
The Composition over inheritance suggests that Car and vehicle does not inherit from each other. To make sure that they both are sharing functionality, the BMW class needs to implement both interfaces.
Let’s say that the following code is where we like to achieve:
x.Drive(); // output : Simply driving.
(x as ICar).Drive(); // output : Car driving.
(x as IVehicle).Drive(); // output : Vehicle driving.
To get there I have introduced three interfaces as follows:
public interface IDrivable
{
void Drive();
}
public interface IVehicle : IDrivable
{
void Drive();
}
public interface ICar : IDrivable
{
void Drive();
}
The BMW needs to implement them as it suites. This implementation has nothing to do with the way they are overloaded.
public class BMW : IVehicle, ICar
{
void IVehicle.Drive()
{
Debug.WriteLine("Vehicle is driving.");
}
void ICar.Drive()
{
Debug.WriteLine("Car is driving.");
}
void IDrivable.Drive()
{
Debug.WriteLine("Simply driving.");
}
}
