Real World Interfaces in C#

I have been on a bit of a “quest” lately to learn interfaces better. While at work I hit up a couple of fellow developers on “why” you should use interfaces in the real world. Believe it or not after going through some code and getting some commentary on it I think I have an understanding of interfaces. Here is my understanding in a possible “real world” situation.

Let’s say you want to render out commonly used objects to the screen. They can be textbox’s, images, or even labels. Each of these might have a common set of properties like title, id, width and height; plus a method like Render() to show it on the screen. Now in .NET we might call these objects controls so we will use that naming convention for example sake. You might create an interface called IControl that all controls will inherit from. One reason to use an interface instead of a separate class is because the render method could be different for all the different controls, but is all that is needed to be called in order to show the control.

So, let’s look at some basic code. First we will look at the interface.

IControl Interface

This interface IControl has our common properties and the render method. We are going to implement different render methods for each of our different controls so we might not necessarily want to create a control class to inherit from. To illustrate this more let’s look at two different controls implementing the IControl interface


TextBox Class Implementing IControl


Label Class Implementing IControl

If you notice both the TextBox and the Label controls have slightly different render methods, but both contain the same properties because of the IControl interface. This is important to note because we KNOW that if the IControl interface is being used that you can always call the methods and properties from them. So that means you can make a method like the following which will always call the render method as long as the object implements the IControl interface no matter what the control is.

OutPut Method that calls IControl Render Method

With this you can create an instance of TextBox and Label and pass both of them to the above method and they will call the render method and output the correct information.

Here is some “example” code on how-to use and put together everything above.

Main Method Implementing Controls


To wrap it up you can make an interface and an interface basically says “hey I have at the very least these properties and methods and you can use them however you need without worrying about what they do to actually use them” Which means that you can write any code you want to implement each of the properties and methods and as long as you use the interface as your “datatype” there is no need to worry about what the code actually does for each and every object that implements the interface. In the case of the example there is no need to worry about how many or what the controls actually do when rendered because they will all be rendered by using the output method since the datatype of the parameter is IControl.

Please, feel free to leave comments and critiques on this. I am still learning about interfaces and this is as “real world” as I could figure out on how to use interfaces as that is what helps learn. Any help would be great and please feel free to download the code I have attached and play with it a bit. I am sorry for the length I just wanted to be thorough, I hope I was. (6.33 kb)

Related Posts:


  1. admin says

    I was talking to a guy int he office a bit about that though I like your idea of the abstract class for the base class. After talking to him and from what you have said I think I am going to extend this post into a series of posts over interface to cover more detail on them.

    This is a fun/interesting subject to learn about and can’t wait to do more research and more posts to learn more.

  2. says

    Be careful with interfaces… they aren’t a golden hammer.

    For example, you could use abstract classes and virtual methods to achieve what you wanted to in your example, with having shared functionality in your base class. This also leads to class mashing once the interfaces do change.

    The point being that when you start working with interfaces, think of them as contracts. If the contract changes something gets broken…

    One common technique is to implement an interface, then create a class (abstract or not) that will implement the interface AND some base implementation.

    In your example, IControl is fine… now define a BaseControl abstract class that defines title, height, width, and ID implentations (since they seem to be exact between subclasses)… That way your TextBox class only has to worry about it’s render method and can still live to the contract and base class. Put another method on your Interface? You are in luck if it has common implementation in the Base Control.. write it there and no more broken code!

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>