Interface versus Abstract class Explained

There are 2 general types of objects that will use an interface. (1) an object that provides services (2) a newbie object that wants to get along well and integrate with existing objects.

Objects that provides services or Service Providers
Take for example your local landline telephone operator, a very big service provider. It provides the “service” of a telephone call from the comfort of your home. Note that the “service” here is actually abstract, in that it is different for everybody. For example, some people may subscribe to a pay-per-call service, some a monthly recurring, some with bundle overseas call etc.  However, there is one certain and common feature for all these services is that it all starts with a telephone line socket installed in your house. In our example here, the telephone socket is the Interface that the telco provides. Whenever we go to a friend’s house, and we see a telephone socket, we know immediately we can make a call to the outside world. We don’t know and don’t need to know which service plan they subscribe to; not even which local telco but we know that we can make the call (except the case where they did not actually have a subscription, which is beyond the scope of our discussion).

In summary, a service provider (telco) exposes an interface (landline phone socket) from which we can consume its service. Whenever we need to use the service (make a call), we just look up the interface (landline phone socket) and communicate through it (in this case, with a telephone).

Newbie objects that integrates with others
Say you want to become the next superstar (In case you already are, congratulations!) or get a career in showbiz, you could try you luck at a reality show like American Idol and Britain Got Talent. When you get there, they will probably ask a few questions like, “Can you sing?”, “Can you dance?”, “Can you act?”. You know if you answer “No” to every such question, you are definitely out of luck, so you could say “Yes, I can sing”. By declaring that you can sing, you actually allow the interviewer to proceed to the next step, which is him saying “Please sing your best song for us”. I could go on the story but at this point we have enough analogy.

In summary, existing objects checks for a particular interface (“Can you sing?”) on a foreign object (you) so that it can make meaningful use of the object (“Please sing your best song for us”) and accept it into the main program (reality show).  If we think about this in another angle, we could also say that you are providing a “singing” service as a singer, hence you are a service provider. But hopefully you can still see the subtle differences.

What? Do it in code please!
Now that we have fully specified our code requirements in english, let’s do it in C#

// Every telco in the world will have the following interface
public interface Telco
    // Telco exposes a property of type PhoneSocket
    PhoneSocket(string number)

// Every singer in the world knows how to sing
public interface Singer
    // Singer exposes a method/ability/action for singing its best song
    void SingBestSong();
// TMobile will look like this
public class TMobile : Telco { }

// You will look like this
public class You : Singer { }

Abstract class
An abstract class is an object which cannot be instantiated. I won’t regurgitate the MSDN documentation, but the fact that it cannot be instatiated, means that it can only be inherited by another class to be of any use at all (except if it is also static). Hence it is similar to an interface: cannot be instantiated, must be “inherited”. The difference is that abstract classes, unlike interfaces, can have implementation and non-public members. Meaning to say, you can actually code into the abstract class how or what a singer should sing.

public abstract class Singer
    // every singer can implement their own best song
    public abstract void SingBestSong();

    // every singer knows how to sing "twinkle twinkle little star"
    public void SingTwinkleStar()
        Console.WriteLine("Twinkle....Twinkle....little star~~~");
// every singer know how to sing twinkle twinkle little star, and also their best song.
public class You : Singer { public override void SingBestSong() { Console.WriteLine("Near..far... where ever you are~~"); }
public class Me : Singer { public override void SingBestSong() { Console.WriteLine("Humpty dumpty sat on the wall!"); }
public class She : Singer { public override void SingBestSong() { Console.WriteLine("three blind mice~~"); }
public class Him : Singer { public override void SingBestSong() { Console.WriteLine("It's my LIFE~~ NOW OR NEVER!!~~");  }

So that’s it, about all how interfaces and abstract classes are conceived. See my next post to see a particular case of struggle between interface and abstract class.