Program to Interface, not Implementation – Beginner’s Tutorial for Understanding Interface, Abstract class and Concrete class

In this article we will look into the details of Interfaces, Abstract class and Concrete class in C#. We will try to understand what each of them are and when should we use interfaces, abstract classes and concrete casses to have a better design for the application.


Every once in a while I see questions on “Interface, Abstract classes and Concrete classes” being asked on the CodeProject Q&A section and many other forums. Most of the time its the beginner’s who are asking the question. The reason such questions are being asked again and again is that the answers to the previous questions(a lot of very good answers) are getting lost in time and number of questions. And thus, I thought about creating this small article on some of the points related to these topics so that this could be used as a reference point for the beginners to understand interfaces, abstract classes and concrete classes.

Using the code

Let us start the discussion by looking at the “What” part. Once we understand this, we can dive into the “Why” and “When” in the later parts of the discussion.

What is a Concrete Class

A Concrete class or simply a class is a language construct that we can use to specify any meaningful entity. Meaningful entity can be thought of as any real world entities or business entities that need to be represented in our application. The other way to look at the class is as a blueprint. A blueprint to represent all the objects that have same attributes and behavior. Let us look at the StudentClass for example.

This Studentclass contain 4 attributes which are exposed as properties. It has single behavior i.e. Retrieving the age(in years) of the student on a given date. The class also contains 4 member variables which are used as backing fields for the 4 properties. In newer versions of C# we can completely do away with the backing fields if there is no implementation logic in the properties. We can do this by implementing these properties as automatic properties.

A Note on Abstraction and Encapsulation

When we talk about designing classes, we need to think about two major things. First thing is “What this class will expose to the the rest of the application/world?” i.e. the public methods and properties. The second thing is “How will we implement these exposed properties and methods?”

Abstraction mainly deals with “What this class will expose to the the rest of the application”? Deciding the public interface of the class that will be used by the rest of the application is called the abstraction. Encapsulation on the other hand deals with the “How we will implement these exposed properties and methods”? This would include whatever code we write inside our properties and methods. This code is actually hidden from the users of this class. This is called encapsulation.

So in a way what we are saying is that the exposed public properties and methods are the abstraction provided by the class. The internal implementation details of the properties and methods are hidden and are encapsulated within the class’ internal implementation.

What is an Abstract Class

In the above code, we have seen that the Studentclass is able to implement all its behavior i.e. all the methods. What if we have a class that does not know how to implement all the behavior. Suppose our student class also need to provide a function GetFee(). But this class does not know how to implement this because the fee will depend on the type of student (assuming the students could be of multiple types i.e Regular and Online). So to represent this let us change the student class in cush a way that it has one method without any implementation.

Now since the method GetFee() doesn’t have any implementation, we need to mark it as abstract. Since one of our function is abstract, we need to mark the class as abstract. What this essentially says is that this class defines a public interface i.e. an abstraction but it does not necessarily comes with an implementation for all the functions. So if someone needs to inherit from this class they need to provide the implementation for all those methods that are marked as abstract methods.

We cannot use abstract class directly because marking a class abstract indicates that this class is meant as a desired abstraction(contract so to say) and whoever wants to inherit from this will have to provide the implementation of the abstract methods.

So to use an abstract class, I created a Concrete class  RegularStudent. This class exposes the same abstraction like  AStudentsince it is derived from Astudent but it also provides implementation for the abstract methods of AStudent.

Now let us take this concept of abstract class to an extreme and think about a class which has all the methods marked as abstract i.e. a pure abstract class.

Now this is a pure abstract class. This means that, this class only provides the abstraction one should provide and it comes with no implementation. So the classes who will derive from this class will have to provide the implementation for all the methods of this class.

Before talking on pure abstract class, let us look at the interfaces first then we will be in a better position to understand all the concepts in a better way.

What is an Interface

Interface is a language construct that let us define a set of methods and properties in it. Any class that implements this interface must provide an implementation of this interface. This looks very similar to the concept of pure abstract class but before we dive deeper let us try to create an interface for our shape problem.

What this interface means is that it provides only the definition of the abstraction i.e. a contract that all its implementer should provide. So to implement the interface we need to provide the concrete class with the implementation of the interface.

So the Squareclass now implements the IShapeand provides the implementation for the IShapeinterface. All the members of the interface are by default public i.e. we don’t need to provide access specifiers in the interface definitions.

Why do we need Interfaces and Abstract classes

Now we know the “What” part of the classes, abstract classes and interfaces. Its time to understand the “why” part associated with the abstract classes and the interfaces. Let us try to understand it in a step by step manner:

The interface and abstract classes are a way of enforcing a contract on the concrete class. So we have to either inherit from an abstract class or implement interface if:

  1. We need multiple classes to behave in a polymorphic way.
  2. We need some kind of contract to enforce on the classes. put the contract in interfaces.

Now the major question is the choice between the interface and pure abstract class as both of them can be used to enforce a contract on the concrete class, which one should be used when. Let us look at some of the points that could help us answer this question.

  • An interface could be implemented by a class and also by a structure which is a value type, not a reference type. whereas the abstract class can only be inherited by classes i.e reference type.
  • Polymorphism based on interfaces is more flexible then the one based on the base class. If we use polymorphism based on interfaces the concrete type can either be of value or reference type.
  • Implementing interfaces is more flexible i.e. A class can have only one immediate base class but it can implement more then one interface. Which would mean that our concrete class can adhere to more than one contracts by implementing multiple interfaces. Which is not possible if our contract is specified as an abstract class rather than an interface.

When should we use Interfaces and Abstract class

Interface: When we only need to enforce a contract. Whoever will implement this interface will provide an implementation of the methods.

Abstract class: When we need to implement a base type that knows how to implement some part of the abstraction i.e. partial implementation and the other/remaining part of the abstraction cannot be implemented by this class. It leaves the responsibility of implementing remaining methods to the classes deriving from this class.

To Illustrate this let us revisit the Shape problem. IShapeinterface is only a contract that says that whoever will implement it will have to provide an implementation for GetAreaand GetPerimeterfunction.

We can have a Circleclass similar to the Squareclass above that can implement the IShapeinterface.

Now we a class like Quadrilateralis needed, we can make this class and abstract class because we can safely find the perimeter of this class by summing up all the sides but we cannot find the area unless the type of the Quadrilateral is known(mathematically it is possible, it is just a hypothetical scenario to design our abstract class).

So this class still implements IShapebecause it promises to fulfill the contract and then it defines itself abstract to indicate that the contract has only been fulfilled partially. If we need to use this class, we need to implement the remaining part of the contract. Let us create a simple Rectangle class to see how it can be done.

We can see in the Rectangle class that it only need to implement the remaining part of the contract specified by IShapeand that is not implemented by the abstract class. The users of the Rectangle class should still work with the IShapehandle. The handle will just be pointing to the concrete implementation of the Rectangle class.

Program to an Interface, not an implementation

Now that we have talked about interfaces, abstract classes and classes, we can summarize the discussion below:


  • Concrete class is the actual implementation.
  • Interface is the contract, it specifies the abstraction contract that its implementer should implement.
  • Abstract class is a trade off between the two i.e. when we need to have the partial implementation of the contract then we can use abstract class.


But why exactly should we care about the abstraction and contracts. Why can’t we simply remove the interface and abstract classes and work with the concrete classes always. We are anyways free to create any number of versions for our concrete classes. Well to find the answer to this question, we need to look at a best practice “Program to an interface, not an implementation”.

What this best practice says is that the application should always use interfaces from other part of the application rather than the concrete implementations. There are several benefits of this approach like maintainability, extensibility and testablility. Anyone can write code that would make the application to work but the differentiating factor is whether or not this code is maintainable, extensible and testable. Let us try to look at these three concepts in details and understand how programming to an interface is always beneficial.

Let us think of a simple component which provides us with a Loggerclass.

Now we need to use this class to log all the error messages. An Admin console also uses this class to get the recent 10 log messages. So the user of the class would do something like:

Now there are two problems here. One problem exist at the Logger component’s end i.e. it is only providing the concrete class and not the interface for the abstraction contract. Second problem lies at the usage end. The user code is actually using the concrete class handle(which can’t be avoided since there is no interface) but also it is using an implementation i.e. string[]for the return type of the GetLast10Messagesfunction.

Now let us see how we can use interfaces and create an application that is maintainable, extensible and testable.


Lets say due to some reasons the internal implementation of the Logger class has changed and the function GetLast10Messagesis now returning a a List<string> instead of a string[]. The moment we take this changed code, we need to make a code change in all the places where ever we are calling GetLast10Messagesmethod(it could be in thousands of places). So it is safe to say that the application is not maintainable. If we want our application to be maintainable then we should have programmed it to an interface i.e. The only use of the data we are receiving from the GetLast10Messagesis with the foreachloop. Now instead of programming to implementation i.e. string[] we should we used IEnumerableinterface instead and it would have worked. Also, when the function start returning List instead of array it will work too because we have programmed our application to an interface and not the implementation.

So the code to use the LoggerBadclass should look like:

Now the return value and internal implementation of the method will have no effect on the using application as long as the returning value implements IEnumerableinterface. Thus making our application more maintainable.


Now we have solved only a part of the problem. If we were the designer of the component then we should have specified an interface for the Loggerclass and implemented our component in this way.

The benefit of this is that our component is fully extensible. If we need to add one more class LogToCloudthen we simply need to implement the contract and our new class is ready for consumption from the application.

By including one interface our component has become extensible. But let us again look at the usage.

There is still a major problem and the problem is that the user class is still programming to the implementation i.e. the LoggerBadand not the interface. If I need to use selectively use LogToCloud, it would be possible for. We need to fix this. To fix this let us program to interface and not to implementation.

Now this class is programmed to the interface and not to the implementation. If we want to use the LogToCloud we just need to pass its concrete class instance and it will use LogToCloud. If we want to use our old LoggerGood, we can pass its concrete instance from the constructor and this class will use that.


Having unit testable applications also mean extensive use of interfaces rather than implementation. This is needed because we can then pass in the MOCK classes while unit testing our components.

The way it is achieved is:


  1. The using class will contain have the interfaces handles from the other parts of the application and use it to perform all the operations. It will not depend on the concrete class.
  2. The actual object of the concrete class will be passed to this class from the outside (Dependency Injection[^]) modules of the application.
  3. Our test project will pass in another concrete object which is a class mocking the actual functionality and implementing the same interface(contract) and thus making our class to use the mock object while being invoked from test project.


Creating Unit testable applications using interfaces itself is a big topic so I will not be discussing it here but to get more information on this please refer: Creating Unit Testable Applications in ASP.NET MVC – A Beginner’s Tutorial[^]

Point of interest

In this article, we have discusses about the concrete class, abstract class and interfaces. We have seen when should we use abstract classes and when should we use interfaces. We have seen how interfaces are used to provide an abstraction contract. We have also seen how interfaces benefit us in creating Maintainable, extensible and testable applications. This article has been written from a beginner’s perspective. One of the motivating factor in writing this article are the frequent questions related to interfaces and abstract classes on CodeProject and other forums. I hope this article was somewhat informative.

Download sample code for this article: CSInterfaceAndClassSample
