C# Interface Based Development

public interface IPencil  
{  
    void Write();  
    bool IsSharp { get; }  
}  
public interface IPencilSharpener  
{  
    void Sharpen(IPencil pencil);  
}

public abstract class PencilBase  
{  
    private bool m_isSharp;  
    private string m_message;  
    public void Write()  
    {  
        Console.Write(m_message);  
    }  
    public bool IsSharp { get { return m_isSharp; } }  
}

public abstract class PencilBase  
{  
    private bool m_isSharp;  
    //private string m_message;  
    void Write(string message)  
    {  
        Console.Write(message);  
    }  
    bool IsSharp { get { return m_isSharp; } }  
} 

public interface IPencil  
{  
    void Write();  
    bool IsSharp { get; }  
}  
public abstract class PencilBase : IPencil  
{  
    private bool m_isSharp;  
    private string m_message;  
    public void Write()  
    {  
        Console.Write(m_message);  
    }  
    public bool IsSharp  
    {  
        get { return m_isSharp; }  
    }  
}

public abstract class PencilBase : IPencil  
{  
    private bool m_isSharp;  
    private string m_message;  
    public string Message  
    {  
        get { return m_message; }  
        set { m_message = value; }  
    }  
    public void Write()  
    {  
        Console.Write(m_message);  
    }  
    public bool IsSharp  
    {  
        get { return m_isSharp; }  
    }  
}

Another place interfaces really shine when we are defining how two classes should interact. The interfaces for each class act as a contract. This contract should be complete and concise so that anyone reading it can understand and implement the interface and write code that interacts with our interface. Take a look at our IPencil and IPencilSharpener interfaces below. You can see how IPencilSharpenes sharpens an IPencil. This is the "30,000-foot view" and helps us and other developers understand the structure of the code on an abstract level instead of having to dig through thousands of lines of code to understand (or remember) how a PencilSharpener and Pencil class interact and the impacts of any changes to either. If you are trying to understand any code, try getting a handle on the provided interfaces first and you are 90% of the way there.

public interface IPencil  
{  
    void Write();  
    bool IsSharp { get; }  
}  
public interface IPencilSharpener  
{  
    void Sharpen(IPencil pencil);  
}

The above interfaces are great, but could be improved because they are not really complete. To have a complete interface "contract" between these two objects, we need a way for the IPencil to be notified when it has been sharpened by the IPencilSharpener so the IPencil can set it's "IsSharp" property back to "true". Can you see a way to improve the interface to complete our contracts and still have reusable, maintainable code?

public interface IPencilSharpener  
{  
    void Sharpen(IPencil pencil);  
}  
public interface IPencil  
{  
    string Message{ get; set; }  
    bool IsSharp { get; }  
    void Write();  
    void OnSharpened();  
}

All we really have to do is add a way for the IPencil to be notified when it has been sharpened. (You probably noticed that I've also added a "Message" property to make the IPencil more usable.) Now any other developer could build pencils and/or pencil sharpeners that will interact with ours if they understand the contracts. Here's how we'll implmement the interfaces.

public class Pencil : IPencil  
{  
    #region Constructors  
    public Pencil(int countBeforeDull)  
    {  
        m_countBeforeDull = countBeforeDull;  
        m_message = string.Empty;  
        m_charsUsed = 0;  
    }  
    #endregion  
    #region Member Variables  
    private string m_message;  
    private int m_countBeforeDull;  
    private int m_charsUsed;  
    #endregion  
    #region IPencil Members  
    public string Message  
    {  
        get { return m_message; }  
        set { m_message = value; }  
    }  
    public bool IsSharp  
    {  
        get { return m_countBeforeDull > m_charsUsed; }  
    }  
    public void Write()  
    {  
        foreach (char c in m_message)  
        {  
            if (IsSharp)  
                Console.Write(c);  
            else  
                Console.Write('#');  
            m_charsUsed++; // used up a character  
        }  
        Console.WriteLine();  
    }  
    public void OnSharpened()  
    {  
        this.m_charsUsed = 0;  
    }  
    #endregion  
}  
public class PencilSharpener: IPencilSharpener  
{  
    #region IPencilSharpener Members  
    public void Sharpen(IPencil pencil)  
    {  
        pencil.OnSharpened();  
    }  
    #endregion  
}

And here's our executing code:

static voidMain(string[] args)  
{  
    IPencil p = new Pencil(20);  
    p.Message = "This pencil should not be dulled any time soon";  
    p.Write();  
    if (!p.IsSharp)  
    {  
        PencilSharpener sharpener = new PencilSharpener();  
        sharpener.Sharpen(p);  
    }  
    p.Message = "That's better";  
    p.Write();  
}

Overcoming a C# Language Limitation

Using C# we can only inherit from one class but can implement any amount of interfaces. Because of this inheritance limitation, we have to be very careful of which class we choose to inherit from because we only get one. This is a place where scalability is negatively impacted. Once we have an inheritance hierarchy set up, it's difficult to change. We can achieve the same results of inheritance through class composition and exposing the functionality of a "wrapped" object through an interface and our classes won't use up our "one shot" inheritance.

For example, if James Bond needed us to develop a pencil, we would have to be very careful how to build it because the requirements will be quite complex: the pencil could possibly be used an underwater breathing apparatus and as a one-shot gun. The pencil also probably blows up if the pencil lead gets too short. Using only inheritance, this would be very difficult without a complex inheritance heriarchy. Using interfaces, it becomes easy. The code below demonstrates how we can indirectly "inherit" from a Pencil through composition and exposing the contained Pencil implementation through an interface.

class BondPencil : IPencil  
{  
    #region Constructors  
    public BondPencil(Pencil pencil)  
    {  
        m_pencil = pencil;  
    }  
    #endregion  
    #region Member Variables  
    private Pencil m_pencil;  
    #endregion  
    #region IPencil Members  
    public string Message  
    {  
        get { return m_pencil.Message; }  
        set { m_pencil.Message = value; }  
    }  
    public bool IsSharp  
    {  
        get { return m_pencil.IsSharp; }  
    }  
    public void Write()  
    {  
        m_pencil.Write();  
        if (!IsSharp) Console.WriteLine("Blows up killing the bad guy!");  
    }  
    public void OnSharpened()  
    {  
        m_pencil.OnSharpened();  
    }  
    #endregion  
}

Now we could also wrap an UnderwaterBeathingApparatus class and it's IUnderwaterBeathingApparatus and a OneShotGun class and its IOneShotGun interface and we effectively have worked around the single inheritance limitation of c#. Notice that we've also added the functionality to the Write() method to blow up bad-guys (the BondPencil is not really meant for writing anyways). Guess what?... Now we're using design patterns and you are looking at the GOF Decorator pattern.

class BondPencil : IPencil, IUnderwaterBreathingApparatus, IOneShotGun 

What's Implementing the Interface

When using the BondPencil or regular Pencil, it would be a good idea to do so through the interface. That way we know that our code will not be broken if someone later comes along and changes the classes or if we ever need to us a different type of pencil (like maybe a mechanical pencil). There will be times we want to know what concrete class we are dealing with so we don't blow ourselves up with a BondPencil. There are a couple ways to do this.

1) The 'is' keyword returns a boolean value and is true if the object can be cast as the type.

if (p is BondPencil) return; // GET OUT OF HERE!  

2) The 'as' keyword is similar to 'is' but 'as' returns a reference to the object if it can be cast or a null reference if it can not be cast.

if (null != p as BondPencil) return; // GET OUT OF HERE! 

3) If we know it is a BondPencil and want to get at some of the other functionality, like the UnderWaterBreathingApparatus, we can force the cast. However, this is not adviseable because if p can not be cast as a BondPencil this operation will throw an InvalidCastException.

(BondPencil) p

Super Pencil

Let's make a mechanical pencil that's self-sharpening. We just need to check that when it needs sharpening, we check that we are sharpening a mechanical pencil, right?

class MechanicalPencil: IPencil, IPencilSharpener  
{  
    #region Constructors  
    public MechanicalPencil(int countBeforeDull)  
    {  
        m_countBeforeDull = countBeforeDull;  
        m_message = string.Empty;  
        m_charsUsed = 0;  
    }  
    #endregion  
    #region Member Variables  
    private string m_message;  
    private int m_countBeforeDull;  
    private int m_charsUsed;  
    #endregion  
    #region IPencil Members  
    public string Message  
    {  
        get { return m_message; }  
        set { m_message = value; }  
    }  
    public bool IsSharp  
    {  
        get { return m_countBeforeDull > m_charsUsed; }  
    }  
    public void Write()  
    {  
        foreach (char c in m_message)  
        {  
            if (IsSharp)  
                Console.Write(c);  
            else  
            {  
                this.Sharpen(this);  
                Console.Write("\nSharpening...\n");  
            }  
            m_charsUsed++; // used up a character  
        }  
        Console.WriteLine();  
    }  
    public void OnSharpened()  
    {  
        this.m_charsUsed = 0;  
    }  
    #endregion  
    #region IPencilSharpener Members  
    public void Sharpen(IPencil pencil)  
    {  
        if (pencil is MechanicalPencil)  
        {  
            pencil.OnSharpened();  
        }  
    }  
    #endregion  
}

An even better way is to make sure our MechanicalPencil can only sharpen itself by modifying the "Sharpen()" method:

public void Sharpen(IPencil pencil)  
{  
    if (pencil.Equals(this))  
    {  
        pencil.OnSharpened();  
    }  
} 

In Summary

As you saw in this article, interfaced based programming is a great way to ensure maintainability, reusability and flexibility in your code. It does take a bit more discipline to carefully define interfaces early in the development cycle, but the payoffs are more than worth it. If the interfaces are kept clear and concise they will not only help other developers understand our code but will also ensure a more stable and flexible code base. Give interfaced-based development a try in your next project, if you follow the basic rules of keeping it simple, you won't regret it.

Until next time,

Happy coding