Click here to Skip to main content
13,628,655 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


88 bookmarked
Posted 27 Jan 2010
Licenced CPOL

Interfaces In Action

, 22 Apr 2012
Rate this:
Please Sign up or sign in to vote.
A basic introduction to interfaces and their usage in development


Just recently, I weighed in on a post where the author was making a legitimate complaint about the quality of articles submitted. I won't go into the details, but since that discussion I've been tempted to write my first article as I think I should try my best and contribute more to the community. Today I commented on another authors post, it was well written and I could follow the thread of the article, but the examples were a little too obscure (for my liking), so their real world application might not be immediately apparent to the reader. So, on to my first article.

It took me a while to grasp the concept of interfaces. It's not that they're particularly difficult as a concept, but how and where to apply them is where a developer can struggle. My intent with this article is not to show anything radically different, not to try and say "my article better describes x" but to try and put my understanding of interfaces and their practical implementation into my words, so that the reader has a different perspective with which to view the topic.


I'm going to make the assumption that you understand (not necessarily are a master of) basic object orientated principals and that you are comfortable with the following words.

  • object
  • class
  • property
  • method

What is an Interface

The simplest analogy I can draw for an interface is that of a contract. A landlord of a property might have a standard contract, everybody expecting to live in a property owned by that landlord agrees that they will adhere to the rules and guidelines contained within it. How two tenants keep within that rule set is entirely up to them, but they are both bound by the same contract. An interface is a guarantee that certain behaviors and values will be available to anybody using an object that implements that interface.


You define an interface in C# as follows:

public interface ICustomAction<T>
     string Name { get;}
     string Description { get; set; }
     T Execute( T val );

An interface is always public. You cannot define access modifiers on the properties and methods defined within and you cannot provide any implementation for your interface.

Note: If you are familiar with C# 3.0's features, specifically auto-properties, do not confuse your interface definition with an auto-property. It is not implementation in the case of an interface.


You cannot create an object of an interface, you can only create an object of a class that implements an interface. Although you will see examples such as:

public void MyMethod( ICustomAction<int> action)

You can never actually declare an object of type ICustomAction. Give it a go, see what happens.

ICustomAction<int> action = new ICustomAction<int>( );

Instead, you need to define a class and implement the interface, defining the functionality that you have agreed an object implementing this interface will provide.

public class UpdateOrderAction : ICustomAction<int>
    public string Name
          return "UpdateOrderAction";

    public string Description {get;set;}

    public int Execute( int val )

Not very useful at the moment. However, you've actually created a class from which you can instantiate an object and you will guarantee it provides a name and a method 'Execute'. Notice that we are now able to define access modifiers on the properties and methods defined. You are however, limited to your properties and methods being made public.

Why Only Public?

As I said earlier, when you define an interface, you are making a guarantee that any properties and methods defined on that interface are available on all classes that implement it. Let us say that Jeff and Bill are writing a system together. Bill is going to work on the back end accounting system, Jeff is going to be working on the front end, data entry system. They're starting their development at the same time, so there is no existing code to work from. Jeff will be allowing data entry clerks to create invoices for customers, Bill's back end system will be responsible for posting those invoices to ledgers etc. So, Bill and Jeff sit down and flesh out the rough design of their system, what they'll need from one another. They agree that an invoice should contain:

  • Id
  • CustomerReferenceNumber
  • Value

So, they define an interface:

public interface IInvoice
    int Id {get;set;}
    int CustomerReferenceNumber {get;set;}
    decimal Value {get;set;}

Now, they both go away happy. Bill knows that he can work with an IInvoice object coming from Jeffs front end, Jeff knows that when he is ready, he can produce an invoice object that implements the IInvoice object they just discussed and he won't hold Bill up. Now, if Jeff decided that when a customer was a high profile customer, he would make the customer reference number private on the invoice, he would not be fulfilling the contract that he and Bill had agreed upon and that the IInvoice interface had promised. So, any class implementing an interface must make all the properties and methods that make up that interface public to all.

Back to the Point

Using the example of the ICustomAction interface from earlier, we'll now continue to try and expand upon implementing our interface in a class. We defined the custom action interface as being of a type, so when we implement the interface in our object, in this case:

public class MultiplyAction : ICustomAction<int>
     public string Name
               return "Multiply Action";

     public string Description { get; set; }
     public int Execute( int val )
           Console.WriteLine( "Name: {0} Value: {1}", Name, val );
           return val * 2;
  • MultiplyAction - The name of the class into which we put the behavior(implementation) of our interface.
  • ICustomAction<int> - This class will implement the ICustomAction interface and will accept integer types wherever T was specified in our interface declaration.
  • public int Execute( int val) - In the interface, this looked like T Execute( T val). We're now implementing it, so it's time for a solid type.

To see this in work, take a look at the sample source code. The generics I used are a little beyond the scope of this article, but hopefully my example code makes them understandable enough. You could define your ICustomAction like so:

public interface ICustomAction
    string Name {get;}
    string Description {get;set;}
    int Execute( int val);

A Brief Summary

In the attached code, there are three custom actions. One is the manager class that has a list of custom actions attached to it, the others are the actions that we can perform. In the program.cs, I create an object of type ActionManager and I add two custom actions to it. Notice that the code only specifies that an ICustomAction<int> is required, not that a Multiply or DivideAction is required.

When Interfaces Come into their Own

Without trying to throw around a bunch of common phrases (such as dependency injection, loose coupling, etc., few of which I believe I have a strong grasp of) Programming to the interface, rather than a solid implementation of an object gives the developers the flexibility to swap out the actual implementation without worrying too much about how the program will take the new change. Back to Jeff and Bill from before. Now, let us say that Jeff and Bill didn't have their original discussion, let us say that the conversation went something like:

Jeff: Hey Bill, so what do you need from my data entry system?

Bill: Well Jeff, I need to get an invoice, I need an Id, a customer reference number and a value. I can just tie up the customer reference number to the account and then post a value on the ledger.

Jeff: Oh great! I'll pass you an invoice just like that.

So, they go away and a week later, Jeff posts an Invoice object to Bill. Great. The system is working fine and they have got it up and running in record time. Their managers are overjoyed, the business is efficient. A month later, Jeff's manager approaches him.

Manager: Jeff, we have a bit of an issue. We're having trouble reporting on the invoices. Some of our customers have the ability to override on an invoice by invoice basis just what terms they have.

Jeff: Hmmmm

Manager: You'll sort it out, that's great!

So, Jeff goes away and thinks long and hard about this. He decides that the best way of doing this is to create a new type of invoice, a SuperInvoice (don't name your objects super anything!). He gets it done in an hour and then implements the change on the system. *BANG*

Bill: Jeff, what happened? The ledger postings crashed, it's talking about an invalid cast.

Jeff: Ooops, we should have talked about interfaces in the first place.

When Jeff implemented the change, he didn't think that Bill was dependent upon an Invoice object. When he implemented SuperInvoice, he just created a new type and implemented it within the system. There are several solutions to this problem, those of you familiar with inheritance may see my example as poor as Jeff could have just inherited from Invoice and all should have been fine. However, what Bill and Jeff originally did do was create an IInvoice interface. It gave Bill and Jeff the ability to program their respective parts without worry of the actual implementation of each object, when Jeff came to implement SuperInvoice, he would have implemented the interface and the system at Bill's end would have been none the wiser. It didn't need to be any the wiser. As far as Bill is concerned, it is an invoice, he doesn't need to worry about whether it carries anything not relevant to his system.


Interfaces are used everywhere throughout the .NET Framework and they are a powerful tool in object orientated programming and design. You may have seen IEnumerable, IDisposable and several others quite frequently while developing other programs. In the case of IDisposable, implementing this interface guarantees you will have a Dispose method on your object (whether you do anything or not[bad practice]).You may see:

using( SqlConnection connection = new SqlConnection( ))

The using keyword will take any object that implements IDisposable. When the using statement is complete, it implicitly calls Dispose. If you define your methods to return an IEnumerable<string> it means you can return any collection that implements the IEnumerable interface and contains strings. You can return a list or any other firm object but you guarantee that the object you return will definitely provide certain properties and methods.

In Closing

Well, that is the end of my first article. Hopefully some found it useful and informative. I do now realise the effort that goes into producing something like this and even though I work day in, day out as a developer I realise just how difficult it is to produce a "real world" example to work with. And I apologise for my criticism of other efforts.


  • v1.00 - Jan 27th '10 - First version


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer
United States United States
I'm originally from the UK, I hail from Saddleworth (near Manchester). I moved to the US in 2007 and live with my wife and daughter in New Jersey.

I started late into software development and do as much learning as I can. I've been a developer for 10 years, starting with Business BASIC on DG/UX boxes, moving to do Windows Mobile development using .NET CF. My tool of choice is C#, however I'll pick at whatever language is good for the job.

I struggle to concentrate on one thing, so don't really learn a topic very well before moving on to the next. It's my aim to sort this out and learn more about C#, the language, the design and more importantly how to use it like the masters I see on this site.

You may also be interested in...


Comments and Discussions

GeneralA bit practical look on interfaces Pin
Member 882354322-Apr-12 15:14
memberMember 882354322-Apr-12 15:14 
GeneralRe: A bit practical look on interfaces Pin
hammerstein0523-Apr-12 0:26
memberhammerstein0523-Apr-12 0:26 
QuestionMy vote of 4 Pin
Reiss13-Nov-11 4:46
memberReiss13-Nov-11 4:46 
GeneralMy vote of 4 Pin
SChristmas12-Jul-11 0:58
memberSChristmas12-Jul-11 0:58 
GeneralRe: My vote of 4 Pin
hammerstein0522-Apr-12 1:28
memberhammerstein0522-Apr-12 1:28 
QuestionYou cannot create an object of an interface? Pin
n.easwaran1-Feb-10 19:34
membern.easwaran1-Feb-10 19:34 
AnswerRe: You cannot create an object of an interface? Pin
RobiProfisoft1-Feb-10 21:06
memberRobiProfisoft1-Feb-10 21:06 
QuestionRammstein fan? Pin
ichramm1-Feb-10 14:40
memberichramm1-Feb-10 14:40 
AnswerRe: Rammstein fan? Pin
hammerstein052-Feb-10 0:48
memberhammerstein052-Feb-10 0:48 
GeneralAuto-properties Pin
Stanislav Georgiev29-Jan-10 23:31
memberStanislav Georgiev29-Jan-10 23:31 
GeneralRe: Auto-properties Pin
MR_SAM_PIPER1-Feb-10 15:50
memberMR_SAM_PIPER1-Feb-10 15:50 
GeneralRe: Auto-properties Pin
Stanislav Georgiev1-Feb-10 20:19
memberStanislav Georgiev1-Feb-10 20:19 
GeneralRe: Auto-properties Pin
MR_SAM_PIPER2-Feb-10 11:39
memberMR_SAM_PIPER2-Feb-10 11:39 
GeneralInterfaces versus inheritance Pin
supercat928-Jan-10 7:04
membersupercat928-Jan-10 7:04 
GeneralInterfaces for Data Objects Pin
HoyaSaxa9328-Jan-10 2:12
memberHoyaSaxa9328-Jan-10 2:12 
RantSuggestion... No... Flame! Pin
Roguer128-Jan-10 1:49
memberRoguer128-Jan-10 1:49 
GeneralRe: Suggestion... No... Flame! Pin
hammerstein0528-Jan-10 2:06
memberhammerstein0528-Jan-10 2:06 
GeneralRe: Suggestion... No... Flame! Pin
Diamonddrake29-Jan-10 12:25
memberDiamonddrake29-Jan-10 12:25 
GeneralYou could also include Pin
Muneeb R. Baig27-Jan-10 20:42
memberMuneeb R. Baig27-Jan-10 20:42 
GeneralRe: You could also include Pin
hammerstein0528-Jan-10 0:52
memberhammerstein0528-Jan-10 0:52 
GeneralYou could include Pin
Ennis Ray Lynch, Jr.27-Jan-10 18:36
memberEnnis Ray Lynch, Jr.27-Jan-10 18:36 
GeneralRe: You could include Pin
hammerstein0528-Jan-10 1:07
memberhammerstein0528-Jan-10 1:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web03-2016 | 2.8.180712.1 | Last Updated 22 Apr 2012
Article Copyright 2010 by hammerstein05
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid