I received a gentle reminder this evening that interfaces aren't contracts. I was attempting to bend Silverlight 2 to my will, specifically the ResourceDictionary. I really wanted the keys, and was pleased to see that it implemented IDictionary<object,object>, which would give me a collection of keys (of object). I was dismayed to see the following implementation in reflector for the Keys and Values properties.
ICollection<object> IDictionary<object, object>.Keys
{
get { throw new NotImplementedException(); }
}
ICollection<object> IDictionary<object, object>.Values
{
get { throw new NotImplementedException(); }
}
This really brought home to me that Interfaces are nice and all, but really only tell us that a type will have methods with a certain name that take certain paramters - exactly the same thing the compiler tells us about lots of other things (that is if you're in a compiled world....the benefits of interfaces seem even more marginal in more dynamically typed duck typing* languages). It doesn't guarantee that the methods will actually DO what we think they'll do (or even that they'll do anything at all except throw an exception in your face). Don't get me wrong - I like and user interfaces, but they're not a contract, more of a gentleman's agreement or shared understanding. Now if you'll excuse me I have some nasty reflection hacks I need to brutally force on the Silverlight run-time.
* Aside: speaking of duck typing, I heard of another interesting turn of phrase for monkey patching - duck punching! If it walks like a duck and flaps like a duck but doesn't quite quack the way you want it to you just punch it [chewie].