Interface based programming, Am I doing it right?

Question

OK so I decided to start using interfaces in my code base and this works out pretty well for certain tasks. For instance I have a URL builder class that implements IUrlBuilder and now the implementation does not matter. Brilliant but take this interface for example.

namespace SproutMessagingFramework.Webtext.Interfaces
{
using System.Net;

public interface ICookieJar
{
    CookieCollection Collection { get; set; }
    CookieContainer Container { get; set; }

    void AddResponse(HttpWebResponse Response);
    void AddResponse(HttpWebResponse Response, string Path, string Domain);
}
}

This interface in my view is pretty concrete, those two methods wont be doing much else than what the concrete class will already be doing. So why did I make it an interface? Well my thinking is what if I need to change the Implementation of AddResponse?

Is this correct or am I just bloating the codebase?

Answer 1

Interfaces can be designed with a 1:1 correspondence to a particular class. This allows (among other things) integration with mock frameworks, where you substitute a pretend cookie jar for the real one while validating the behaviour of a cookie monster in a test environment.

It is more common, however, for interfaces to define a subset of the class's capabilities, and can often be orthogonal in purpose to the class itself. A good example of an orthogonal interface is IDisposable. A class implements IDisposable when it wants to support clean reclamation of unmanaged resources such as sockets, file descriptors, etc., though resource cleanup is not what the class is really designed for.

Another common use is to provide a unified container model, such as ICollection and IEnumerable.

Finally, classes often implement several interfaces, usually corresponding to orthogonal cross-sections of their capabilities.