More OOP: Interfaces in C#, Part 2

Yesterday I introduced you to Interfaces in C#. There’s a bit more about interfaces I wanted to share. With a normal class, it can only inherit from one base class. However, it can implement multiple interfaces.

By the way, this seems like a good time for a little lesson in terminology. A class inherits from another class, but it implements one or more interfaces.

Let’s look at our IPerson interface from yesterday. For various reasons our architect has decided it should actually be implemented as two interfaces, one with the properties and another with the method. (For demo purposes I left both interfaces in the same file, in real life I would have each in it’s own file.)

using System;

using System.Collections.Generic;

using System.Text;


namespace OOPDemo


  public interface IPersonP


    string FirstName { get; set;}

    string Lastname { get; set;}



  public interface IPersonM


    string FullName();





Now we need to modify our Employee class to implement both methods.


  class Employee : IPersonP, IPersonM


Notice all it took was separating the interface names with commas. If we were also inheriting from a base class, we would list it first. Yes, you can both inherit from a single base and implement one or more interfaces for a class.

Finally, we need to make a quick update to our ShowName, since the old IPerson has been replaced with an M and P version:  

    private void ShowName(IPersonM per)


      MessageBox.Show(per.FullName(), “ShowName Method”);



You need to be careful when designing your interfaces, not to get too focused. In the above example, what if in the ShowName method you need to also access the FirstName property? Can’t do it with the code as it is now since IPersonM knows nothing about those properties. Instead you’d have to pass in an Employee, in which case we’ve limited our functionality. The ShowName would no longer be able to accept a Contractor or Vendor (assuming we ever created them).

So, we know that a good time to use an interface is when you have a base set of properties and methods, but not code, that you wish to share among classes so that you can treat them as the same generic type. What other times might you wish to use interfaces?

In his book Programming .Net Components ( Juval Lowy has an entire chapter devoted to interface based programming. When writing a class library (i.e. a dll) Mr. Lowy suggests only exposing interfaces. Why? This leaves you totally free to redesign even your base classes.

Even further, Juval advocates placing all of your interfaces into their own class library. Because it’s fairly quick to create interfaces, it allows both the user interface team and the class library team to get to work, both referencing the same interface dll.

A final reason for using interfaces is to extend your class so that it is compatible with items in the .Net Framework. .Net exposes a slew of interface types, and you can implement any of them in your classes.

A common example is the IEnumerator interface. If you were to implement the IEnumerator interface in your class, you could then use your class anywhere you would use an enumerator in .Net, such as in a foreach construct.

Hopefully by now you’ve seen the power of an interface, and will begin using them in your own applications.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s