Have you ever wondered how electricity works when you plug something in? You don’t need to, you just know that you when you have an electronic device, it just needs a plug to fit into the interface.

 

 

 

 

 

 

I can buy a blow dryer, a fridge, or any type of electronic device that has that 3 socket plug, and it works.  All these devices implement this interface and follow the rules given to us by the wall sockets.  If I create a flux capacitor and need it to run on electricity, then I have to make sure the plug implements the interface of the wall socket, so that it can use the electricity coming from the wall socket.

Let me start by saying that this concept isn’t new, and it has been mentioned in various books written on the dependency injection pattern.  Don’t worry too much about what the dependency injection pattern is, as that is another couple of articles in itself.  This article will concentrate on one of the fundamentals of it, and it should catapult you into captivating a better understanding of dependency injection.

Even if you don’t care about dependency injection, Interfaces are crucial to writing efficient code.    Like many developers, I didn’t see the need to use interfaces, and would just code using concrete classes.  In my head I thought using interfaces was too much overhead, where I really didn’t see the benefit.  When I would speak to other colleagues, they said, “Yeah, it’s better to keep it simple and not use interfaces”.  What I didn’t realize is that programming to an abstraction makes for more extendable and maintainable code.  So I’m dedicating this article to the fundamental concepts of interfaces, and how you can apply them to your coding.

An interface is a reference type that is used as a contract for what actions an object can take. This means that any object that “implements” an interface, must define all the methods within that interface.  An interface can never have any definitions, and cannot be instantiated.  Interfaces are all about action and behavior, and not about data.  When considering using interfaces, think about the behavior and action, and if it fits into what you’re trying to accomplish.  Let’s take the following example:

 

public interface IMessenger

{

string Send();

}

 

The need for my application is to send out messages in email format to recipients.  Now I’m free to choose of a way to send messages using this interface.  I can create a class called EmailSender, and it can implement this interface with its own concrete implementation.  I can do the following:

 

public class EmailSender : IMessenger

{

string IMessenger.Send()

{

// concerete email implementation

}

}

What if I needed to also send text messages?  We can create another concrete class to implement my IMessenger interface:

 

 

public class SMSTextSender : IMessenger

{

string IMessenger.Send()

{

// concerete email implementation

}

}

 

Now all you have to decide is when to use one over the other.  You can instantiate them:

IMessenger iemailmsg = new EmailSender();

IMessenger itxtmsg = new SMSTextSender();

..

iemailmsg.Send();

 

We can keep them separate, and don’t have to mix functionality between them. Our SMSTextSender class will have its own logic, and the EmailSender class will also have its own logic.

Suppose you had your own implementation of EmailSender because you are going to eventually replace it with a new and improved version of it. You create the following:

 

public class ImprovedEmailSender : IMessenger

{

string IMessenger.Send()

{

// concerete email implementation

}

}

Then you would only need to change your instantiation:

IMessenger iemailmsg = new ImprovedEmailSender();

..

iemailmsg.Send();

 

Next time you are writing an application, think about that wall socket, and how you can create interfaces for your application so that anyone that wants to come along, can plug into your interface without a problem.

Interfaces – Concepts You Should Know Before Diving into Dependency Injection

Leave a Reply

Your email address will not be published. Required fields are marked *