Are Interfaces under-used?
I am often asked about Interfaces, and why should they be used. I do think that they are not used as often as perhaps they should, instead, people use a full blown class as a base that provides little value. I know when I was learning Java and C#, Interfaces were one of the more challenging aspects of the implementation of the OO rules as set down by Sun and Microsoft. Although fully conversant with OO, it was often quite difficult to really appreciate the value of an Interface. And then, one day ... it clicked. I think this is true for most people. I certainly so little benefit from Microsofts own documentation, I got a bit of an idea of their potential on the MS C# training course I attended but I became enlightened when working on a particular project with a particular configuration of classes.
So, although in many respects it is very simple, I thought it would be of value to summarise why I find interfaces useful. Hopefully, this will pop up on Google and help someone else achieve a higher level of coding-spirituality - and give me good Karma to boot!
Definition of Contracts
The core value of an interface is to define an interface to other objects that may interact with it. Browsing through the various collections will reveal three interfaces that are very useful: ICollection, IList and IEnumerable. These three classes define different functionality for any number of classes that implement them. An interface is nothing more than a "template" that - when provided to a function or object, can be used regardless of the originating type.
For example, I have an Interface that defines a SQL Portal, which may be used by different types of class for different types of database:
public interface IDataPortal
{
string ConnectionString { get; set; }
DataRow GetRecord(string tableName, IDictionary primaryKeys);
DataTable GetRecords(string tableName, IDictionary criteria);
DataTable GetRecords(string tableName, IDictionary criteria, string sortBy);
IDictionary SaveRecord(string tableName, IDictionary primaryKeyHash, IDictionary dataHash, bool isNew);
int DeleteRecords(string tableName, IDictionary primaryKeys);
}
Marker Interfaces
An Interface does not need to define any members, as is the case with the INamingContainer interface provided by ASP.NET. Developing a WebControl without this interface will generate HTML with names that cannot be guranteed to be unique and therefore are not supported by the server. Add the INamingContainer interface, and ASP.NET starts to output spurious ID's, which it can use to manage the state of a web page across post backs.
This is a snippet of the code I posted for the FormLabel control:
public class FormLabel : WebControl, INamingContainer
Casting across Base Classes
To be able to use a set of classes as the same type of class, you would commonly use a base class. But sometimes there is no need to use a base class - and implementing a base class may have implications on the future maintenance of the class model. An interface implemented by one or more classes can provide the same purpose to allow casting across different types of classes and have them dealt with in the same way.
Extends Flexibility
By using a common Interface across a number of similar classes, it is possible to improve the opportunity to use different classes - but still use the same functionality. For instance, if a Property accepts a list, don't tie it down to an ArrayList and require that particular type of object to be used, use a common interfcae such as IList or ICollection that supports what you need in the property or function, but gives the consumer the flexibility to create a more logical object.
public CopyListToSomething(IList iList, object something)
Hopefully this has provided some different uses for Interfaces. If anyone has any more, or disagrees, let me know ....