Like This Blog 3

Added by Dan Wahlin August 7, 2013

Video transcription

 Dan Wahlin:

One of the topics that I get the most feedback or comments or questions about is C# Interfaces. What are they? Why would I use them? Why are they important in our applications? What I’m going to do is try to break down C# Interfaces in just a real short little segment here and make some sense of why you might use those in your applications. The short answer is we’re going to use C# Interfaces to drive consistency.

Let me show you what I mean by that. Let’s take a look at a little visual here.

Imagine that I have a factory and in this factory, we’ll say times are tough, and I have a single worker. I only want to train them on one methodology for starting and stopping machines.

[0:47] For example, I have a square machine, a whatever‑that‑shape‑is machine, because I honestly don’t remember, triangle machine, and all those types of things. Each one of these has a start and a stop and you’ll notice, visually, that they’re actually green for the start and red for the stop.

Now, I think you look at that and say, well, that’s pretty simple. I get that you only have to train the worker once to press green for start, red for stop, and that’s a consistent visual Interface.

[1:15] Now, let’s imagine that these, instead of being machines, are Classes, and the Classes need to have start and stop methods. How are you going to drive consistency across these three different Classes, and you might have more than that, and do so in a way that kind of adheres to the standard in the .NET framework? One of the ways we can do it is Abstract Classes. But in this particular segment, we’re going to focus on Interfaces.

Interfaces provide a way where, if you have objects that aren’t even similar to each other but you want to drive a consistent Interface, consistent set of methods that they support or properties, then you could write an Interface that they all implement. I’m going to demonstrate that here.

If we do a demonstration of this, which I’ll do in a moment, you’ll see that Interfaces provide a great way to drive consistency across objects. That’s kind of summed up here as far as the purpose of Interfaces.

[2:13] Number one, they just provide consistency. You’ll also see that they provide some Polymorph ic benefits, which I’ll talk about here at the end.

Interfaces, in a nutshell, are simply a code contract. If you go and buy a house, you’re going to assign some type of a mortgage contract that says you agree to pay whatever it is per month.

[2:33] Well, in the C# world, if I want to drive consistency and say that a set of objects has a start and a stop method, and I want all of my objects to have that, then one way I can do it is to implement an Interface. That’s a contract that says, “I hereby agree to put a start and a stop into my Class.”

Interfaces themselves, which we’ll see in a moment, do not have any implementation details. In fact, Interfaces are really simple and they don’t do anything, except find data types and names. I’ll show you that in just a moment. Then, Classes that implement the Interfaces, that’s like going to the mortgage broker or the bank and agreeing to pay whatever it is per month for that particular mortgage.

[3:19] In the case of coding, a Class that implements an Interface is signing their name on the dotted line that they hereby agree to put in certain methods or properties, as defined by the Interface.

Let me show you an example here in Visual Studio. I’m just going to come in and let’s create a real simple project here.

I’m going to do a console project. Let’s go ahead and select “C#,” “Windows Console.” I’m going to call this, “Interfaces Demo.”

We’ll go ahead and save that away. We now have a Class called “Program.”

What I want to do is add some other Classes in. These other Classes actually support maybe an Interface.

[4:07] Let’s define what the Interface is and let’s do exactly what I showed you earlier. We’ll come in and we’ll add a new item. One of the items I can add is an Interface you can see here.

That Interface, I can give it whatever I want, let’s just call this “IMachine.cs”

You’ll notice that I started it with a capital “I.” That is a convention in .NET that you should follow. You certainly don’t have to, but I’m a big fan of it, and you’ll see that throughout most .NET programs.

[4:40] What an Interface defines is simply some basic members. Let’s say that there’s a Boolean return from a start and from a stop.

There you have it. That’s an Interface.

[4:51] You might look at and say, “That doesn’t even do anything.” You’re right. Interfaces do nothing. They simply define different members, start and stop in this case, and what they return, but they don’t actually have an implementation, as I mentioned earlier.

What we can do with this Interface, though, is, let’s say that we have a car.

That car might have maybe a start and stop. We’ll come on in to “Class,” we’ll do a car, and we’ll say this car’s also public.

I’m now going to implement that Interface by saying, “IMachine.”

[5:30] Typically, you’ll see a lot of names in Interfaces that are actions. I could have called this “I Startable Stoppable,” or some goofy name like that, but we’ll go ahead with something simple, like “IMachine.”

If I try to build, watch what happens here.

We get two errors. That’s because it says, “Car does not implement.” Of course, we have to implement “Start” and “Stop.” Otherwise, it’s not going to work properly. I could go to the trouble to write all that code to make this Class implement the contract that we signed, now. This is like signing the dotted line, right here.

[6:05] But instead we can just right‑click on it and say, “Implement Interface,” and then choose this first one, “Implement Interface Again.”

That pops in the code for us.

Then we can come in and do something simple here. We’ll say, “Car Started.” And we’ll take this one out, and we’ll do the same thing, and we’ll say, “Car Stopped.”

[6:28] Of course, you would go in and write a real implementation and do something a little more official, and then we have to return a boolean. I’m going to assume our car always works, because ours is a very good car, and we’ll just return “True.”

But in a real app this is of course where you would go in and figure out what should be returned based on the database update succeeded or whatever it was you were doing.

Now let’s try to build, and you can see we built.

Now we have implemented an Interface.

[6:56] At this point, though, you might go, “I don’t know what that’s really buying us.” Let’s say that we also had a lawnmower. A lawnmower obviously is not an automobile, or something like an automobile, so we can’t really inherit or use abstract Classes, but I can drive consistency across the car and a lawnmower by using Interfaces. What we can do is do a lawnmower, and we can do the same thing.

I’m going to again say that we’ll assume this is public, and we’ll implement “IMachine.”

I’ll then right‑click, implement the Interface, and we’re off and running.

Now I can basically do the same thing. Let me just write a little bit of code real quick, “Lawnmower Started.” And we will say that we also have very trustworthy lawnmowers that never go down.

And we’ll do a Console.WriteLine here, “Lawnmower Stopped.”

At this point, we have now driven consistency across our app, and we can now use this to actually do something. Now let’s come into Main of our program.

[8:13] We can fire up a car. Notice when I do “Car.” you’ll see “Start” and “Stop” in there.

Then we could also fire up a lawnmower. When I do “Mower.” you’ll also see “Start” and “Stop.”

At this point, you might say, “I don’t really see the benefit.” Really, all we’ve done at this point is driven consistency across two objects that wouldn’t necessarily inherit from the same base Class.

[8:46] It’s possible they could. I suppose you could argue that you might have an abstract Class called “Machine,” or something like that, that has “Start” and “Stop” that you inherit down. But by using Interfaces, the objects don’t even have to be directly related through inheritance, and yet I’m able to drive consistency across these objects. Pretty cool.

What we’ll do in a follow‑up to this is show where this gets really useful with Polymorphic Behavior, but we’ll end here by talking about, This is the role of Interfaces, what you can do with them, and how you can drive consistency across Classes with Interfaces.

In the next video post, we’ll see how to “future-proof” our apps using Polymorphic Behaviors in our C# Interfaces.

Dan Wahlin Microsoft MVP
.NET Developer Instructor
Interface Technical Training