Long before I started coding, Microsoft implemented Interfaces into the .Net framework. This was a significant improvement for object oriented programming, improving on the core principles of inheritance and abstraction while overcoming large obstacles.
Inheritance and abstraction are 2 of the 4 principle pillars of object oriented programming (OOP). The 4 pillars of object oriented programming being inheritance, polymorphism, encapsulation and abstraction. In my opinion, these 4 principles are what make OOP most enjoyable to work with. Procedural code has its place, but isn’t nearly as fun to build with for me. Moving on.
Before Interfaces, when you were developing a class, you could inherent from a base class. You were limited to a single base class, which sometimes was really annoying. This required additional planning and sometimes major retooling to make sure the program made sense.
This concept of single inheritance is demonstrated when the sub class named the “dog” inherits from the base class named the “animal”. In inheriting from animal, dog inherits the methods, properties, indexes, and events of animal. This example of inheritance however has one very large limitation, the inability to inherit from multiple classes. Classes are limited in in how they are inherited unfortunately.
To overcome this limitation on inheritance a group of really smart people developed Interfaces, which allow for multiple inheritance, but they also developed a few rules.
Liskov’s Substitution Principle (LSP)
Before we start inheriting from many base classes it is important to remember the Liskov’s Substitution Principle (LSP). LSP basically states that a subclass should not inherit from a base class anywhere that the subclass could not itself be rendered in place of the base class. You can find more on the principle here. By adhering to LSP we ensure that the contract between our base and sub classes is respected and that their behavior is predictable. A sub class should not for example throw an exception in a method where a base class would allow and return a value.
Another rule was in implementation, you couldn’t halfheartedly inherit from a Interface. If you chose to inherit from an Interface, you had to implement each of it’s methods.
Unlike a base class, an interface doesn’t actually provide and of the how-to for its methods. Instead, think of an Interface as an abstract class with the implementation stripped out. It is up to the derived class to provide the how-to for each of the Interfaces methods.
Why would you want to implement an Interface then?
Using an Interface allow a loose coupling of components, this is a key to the other pillar of OOP mentioned above: Abstraction.
The principle of abstraction is a process of hiding the implementation details and showing only functionality to our user. That sounds a lot like what an Interface does doesn’t it?
The Interface design also allows us to institute a plug and play type structure into our application. We design what a class is going to implement, and by making them promise to use the layout we have provided we are able to swap parts in and out. This allow our core blueprint to remain regardless of changes. This is a key to building maintainable component based applications.
I hope this helps explain things better. OOP rules!
A Web Developer by trade, future data scientist.
A motorcycle enthusiast at heart.
Most days I’d rather be in the woods anywhere.