Can you inherit from multiple classes in C#? No, the language doesn’t support it however there are ways around it.

From a design perspective you have to ask yourself, Will a Class fully represent an object? Meaning that, if we have a base class with abstract methods designed for a particular application and we know that the inheriting object will only need the methods defined in that class. We now have a valid design pattern here.

The Vehicle Car Object

Lets say we have an abstract class called “Vehicle” as well as another class called “ConstructionVehicle”. The vehicle class has methods such as Accelerate() , Stop(), and the “ConstructionVehicle” class has methods such as ExecuteDump() and TurnOnBackUpSound(). If we were only going to build a Car object and know we would only use those methods from the “Automobile” class this would be fine.

The DumpTruck Object

Now we want to create another object called “DumpTruck”. We could inherit from the Automobile class but that class does not have the methods that we need called ExecuteDump() and TurnOnBackUpSound(). If we were using a language such as C++ we could easily inherit from both classes using multiple inheritance. However, seeing C# is our language of choice, multiple inheritance is not an option, you may only inherit from one Base Class.

From Abstract Classes to Interfaces

From a design perspective we must choose a different design. C# supports what is called “Multiple Implementation”, which is to says a class can implement more than one interface. Our design now changes the “Vehicle” class and the “ConstructionVehicle” class into interfaces. Below we have

defined the two interfaces with their very simplistic methods:

interface IConstructionVehicle


  void ExecuteDump();

  void TurnOnBackUpSound();


interface IVehicle


  void Accelerate();

  void Stop();

  void TurnOnBackUpSound();


If we built a class that inherited from these two interfaces we would be able to do so spanning multiple inherited interfaces. Design problem solved!

Or is it?

Explicit Interface Implementation

If you look at both interfaces defined above you’ll notice that they share in common a method of the same name “TurnOnBackUpSound()”. Problem? No, in fact C# supports what is known as “Explicit Interface Implementation”, which allows the programmer to specify which member of

which interface they want to use. Putting the Interface name in front of the member name allows this to happen as shown below.

public class DumpTruck: IEngine, IBody


  void IEngine.Test()


    Console.WriteLine("This is the Engine TEst");


  void IBody.Test()


    Console.WriteLine("This is the Body TEst");



Implementation Hiding

Another benefit to this technique is something called “Implementation Hiding”. Implementation Hiding allows the methods from the implemented interface to be hidden from the derived class unless the developer explicitly calls the interface. This technique obviously reduces the clutter for a developer.

From a theoratical point of view MI has it’s place. In many situations we need to make a decision whether to define an interface or an abstract class with same signatures. An interface and abstract class are exactly the samething except abstract class would allow some non-abstract members which can act as shared common code plus it can have protected overridable members. If MI is not supported then I have to really think whether to put my signatures in interface or an abstract class and decision would be based on limited knowledge whether client classes could have been already been derived from other class.

Microsoft says:

1. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation.

2. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.

So in nutshell, there’s no simple answer. If there is no MI, your ability to share common code along with abstract members might be limited but you might want to first consider refactoring your code and design before blaming the limitations of a language.