I find my self in the middle of lots of sticky API design issues.  Usually we have a couple of pretty clear options with well known pros and cons.  Sometimes the battles get pretty heated between people arguing for one option or another and some well meaning PM suggests “let’s just do them both”… It is hard to seem reasonable and argue with that - after all both sides got what they wanted right?  Maybe, but the poor user is in a net worse place.  If we’d just decide on an option and get 100% behind it we could make the world SOO much better.   There would be net fewer types and methods in the system and the ones we’d have would be better!


I had another one of those issues come up today.  A team coming in for API reviews had a base class, let’s call it “Foo” (so as to not spoil any of the fun from the PDC) and an interface called “IFoo” that represented exactly the same contract.  So I ask why they have both.  Well, it seems that some clients wanted and interface and some wanted a base class.  In other words, they couldn’t decide.  So I ask, when you expose methods that take with Foo’s what are you suppose to use? Foo or IFoo? When would I use one over the other?  Do your methods take Foo and IFoo?  We had the same problem with Component and IComponent and eventually had to add specific test cases to make sure IComponent kept working because most everything derived from Component, it became the defacto standard.  Having IComponent there to support a niche scenario adds net complexity to the system.  I think the same is true for today’s Foo\IFoo case.  In the end we decided to the vast majority of scenarios were satisfied by just using the Foo base class.  


I think the world got every so slightly better today because we took away an option…. Score another point for addition through subtraction.