API Design Myth: Interface as Contract
I often hear people saying that interfaces specify contracts. I believe this is a dangerous myth. Interfaces, by themselves, do not specify much beyond the syntax required to use an object. The interface-as-contract myth causes people to do the wrong thing when trying to separate contracts from implementation, which is a good engineering practice. Interfaces separate syntax from implementation, which is not that useful, and the myth provides a false sense of doing the right engineering.
Contract is semantics -- and these can actually be expressed with what many unjustifiably consider unwanted implementation. For example, the contract of IList<T> says that when an item is added to the collection, the Count property is incremented by one. Such simple contract can be expressed and what’s more important locked for all subtypes, using something like the following abstract class.
public abstract class CollectionContract<T> : IList<T> {
public void Add(T item){
AddCore(item);
this.count++;
}
public int Count {
get { return this.count; }
}
protected abstract void AddCore(T item);
private int count;
...
}
Comment Notification
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
