I was recently asked for some good reading material on the difference between implementing and injecting interfaces and I couldn't come up with anything. I know the root cause of the lack of material is that the two concepts are totally different, but they are related so it's worth discussing them together.
First let's look at what an interface is in object-oriented programming. The simplest way to think of interfaces is as contracts. If you hire a crew to paint your house you're going to sign a contract with them. You've defined in the contract exactly which parts of the house need to be painted, the color of the paint in each area, and perhaps some small improvements to be done as they paint. When the painter agrees to take on the job, he's agreeing to implement that contract exactly as you specified.
An interface in programming is
exactly the same as the contract we had the painter agree to. If we define an interface we're saying that any classes that want to agree to (implement) that interface
must be structured
exactly as the interface specifies. Let's take our painting example virtual and define our contract as an interface.
1: public interface IBindPainters
2: {
3: List<Improvement> Improvements { get; set; }
4:
5: Dictionary<Location, Color> Colors { get; set; }
6:
7: void Improve(Improvement improvement);
8:
9: void Paint(House house);
10: }
Any painter classes we create that want to implement (agree to) this interface (contract)
must have a property called Improvements, a property called Colors, and methods called Improve and Paint. The signatures of the methods and types of the properties must also match the interface. So if we create a class called JohnPainter that wants to implement this interface it would
at least look like what you see below.
1: public class JohnPainter : IBindPainters
2: {
3: public List<Improvement> Improvements { get; set; }
4:
5: public Dictionary<Location, Color> Colors { get; set; }
6:
7: public void Improve(Improvement improvement)
8: {
9:
10: }
11:
12: public void Paint(House house)
13: {
14:
15: }
16: }
If we create a class called FrankPainter that wants to implement this interface, it would
at least look like what you see below.
1: public class FrankPainter : IBindPainters
2: {
3: public List<Improvement> Improvements { get; set; }
4:
5: public Dictionary<Location, Color> Colors { get; set; }
6:
7: public void Improve(Improvement improvement)
8: {
9:
10: }
11:
12: public void Paint(House house)
13: {
14:
15: }
16: }
Both of those classes implement the interface, which means that both John and Frank have agreed to our contract.
That's literally all interfaces are for! An interface doesn't specify
how the work gets done - Frank and John might each paint that house using completely different processes - and it doesn't actually
do anything. It just guarantees that whoever implements the contract agrees to the terms.
So the next question that usually comes up is
Why? Why do we use interfaces at all? Well, let's keep moving forward with the house painting example we've been using and see if we can answer that question, too.
As the homeowner, I know how the process of having my house painted is going to work. I'm going to hire a painter, give them the colors to paint each part of the house, show them the improvements that need to be made, have them do the improvements, then paint the house, then I'll pay them. Before I hire the painter, I can define my entire process, like this:
1: public class HomeOwner
2: {
3: private IBindPainters _hiredPainter;
4: private House _house;
5:
6: public HomeOwner(IBindPainters hiredPainter)
7: {
8: _hiredPainter = hiredPainter;
9: _house = new House();
10: }
11:
12: public void HaveHousePainted()
13: {
14: _hiredPainter.Colors = new Dictionary<Location, Color>();
15: _hiredPainter.Improvements = new List<Improvement>();
16: foreach (var improvement in _hiredPainter.Improvements)
17: {
18: _hiredPainter.Improve(improvement);
19: }
20:
21: _hiredPainter.Paint(this._house);
22: }
23: }
So what does this do for us? Well, we know that whatever painter we hire they're going to have to agree to our contract, so we can setup our entire day before we know who is going to actually paint the house. If we decide to hire Frank we just pass Frank as the painter into our constructor and everything works fine. If we decide to hire John we just pass John as the painter into our constructor and everything works fine.
Since our constructor is expecting an interface (IBindPainters) what it's
really expecting is a
class that implements that interface. Whether that class is John or Frank makes no difference to how we're going to have our house painter. Whoever we hire is going to
have to agree to our contract.
This really comes in handy when we don't know ahead of time which class we'll get. Let's say I'm not the one picking the painter; it's my wife instead, but she can't be home when the painter shows up. She leaves me very clear instructions on what to do when the painter gets there (give him the colors and areas to paint those colors, show him the improvements, have him make the improvements, then have him paint), but she forgets to tell me who she hired. Well, it doesn't matter as long as the person who shows up agrees to the contract.
When the painter shows up - whoever it is - we just plug him into our predefined process and he gets to work. Guess what?
That's what injecting an interface means! Injecting an interface just means we provide a class that implements the interface, but we depend on (expect) the interface instead of a specific class.
Let's recap.
- An interface is just a contract; it cannot be instantiated itself
- When a class implements an interface, it just means that class agrees to the terms of the contract
- Injecting an interface means we expect a class that implements an interface to be provided
- Interfaces do not actually do anything... ever!
Hopefully this helps you out if you've been trying to understand interfaces and/or injecting them.
