Part One: Interfaces in C# – Whats the point?

Whats the point?

That’s a really good question. To be honest, I have asked myself this question a number of times and have failed to answer it. So I made a conscious effort to find the answer. Why should I care about interfaces? What’s the point? The first thing we need to do is understand what an interface is.

 

An interface is like a contract. You are responsible for implementing what the contract tells you to.

 

Sounds catchy, but what does it really mean? The interface defines what you are responsible for. Lets play this out with a scenario:

  • Company ABC has two job vacancies. One is for a secretary and the other is for a security guard.
  • The company interviews and hires Margaret for the position of secretary.
  • Fred is hired for the security guard position.

Margaret and Fred both receive a contract from Company ABC. The contracts for Margaret and Fred both contain the same definitions

  • Employee Name
  • Holiday Entitlement
  • Working Hours
  • Job Description
  • Responsibilities

Both contracts contain the same definitions, however, there are differences between both.

[table id=2 /]

From the above we can see that both contracts implement the definitions, but with different ‘values.’ The contract stipulates that Margaret and Fred must work the hours that are defined in their contracts, but the hours for both differ. We can take this and turn this in to ‘developer speak’ as follows

 

The contract defines what must be implemented. It does not define how you must implement it!

 

In fact, the contract doesn’t care how you implement the definitions, it just cares that you have done it.

 

I’m a developer. What does this mean to me?

That’s another good question. Lets assume that you are responsible for writing a program that will be used to create the contracts for Company ABC. They hire lots of people every year so produce lots of contracts (one for each member of staff, right?). The program you create should ensure that all contracts contain the correct definitions.

Lets have a sneak peak at what the interface could look like

public interface ICompanyAbcContract
{
  string EmployeeName { get; set; }
  int HolidayEntitlement { get; set;}
  int WorkingHours { get; set; }
  string JobDescription { get; set; }
  string Responsibilities { get; set; }

  void GenerateContract(); 
}

Lets break it down in to its parts. The first thing that we have done is declared a public interface called ICompanyAbcContract. Later on, we will create a class that will ‘implement’ this interface.

public interface ICompanyAbcContract

The interface contains the following declared members. Everything that is declared in an interface is automatically public. Why? Think about Fred and his contract. If parts of his contract were blacked out how would be know what he had to do? Worse yet, what if someone forgot to add the section in for HolidayEntitlement. Poor Fred wouldn’t be entitled to any!

Finally, a method has been declared, ‘GenerateContract’ which by its name should be obvious what it is intended for.

  string EmployeeName { get; set; }
  int HolidayEntitlement { get; set;}
  int WorkingHours { get; set; }
  string JobDescription { get; set; }
  string Responsibilities { get; set; }

  void GenerateContract();

So we have some properties and a method declared. There are only two other signature types that can be declared in an interface; indexers and events. We don’t need any here.

So, we have our interface (aka contract) defined. So when we come to implement our interface we will know what we must implement! The interface contains what we know we need for every implementer. In other words, our contract contains the common definitions that all employees at CompanyABC need to know about.

In Part Two, we will implement our interface and start to put it to good use!