Interface first?

I've been re-reading this post from Sikin Joseph for most of the afternoon.

...I got it into my head that I should "Always program to an interface not an implementation". So whenever I needed to create a new class/abstraction I used to start of with an interface IThis, IThat etc. over a period of time I saw that most of my interfaces were only ever implemented by one class. This started becoming a pain to maintain as adding a new method meant that the method needed to be added to both the interface and the implementation class, further since there was only one implementation of the interface some developers started substituting one for the other and freely casting between the interface and the implementation. This became a source of constant code review changes and eyesores in code, with some methods expecting interfaces and others expecting the implementation class.

 I identified with his problem immediately - recently I have been using the Smart Client Software Factory from Patterns and Practices (except not in C# but in VB.NET, so the nice GAT recipes aren't there). Their pattern of web service proxies is really nice, and the Model-View-Presenter pattern is also useful. However, I found on the first app I wrote using these two patterns, a change in the web service WSDL (usually for method parameters) caused a large cascade of code changes - in the command class parameters, in the interface code, in the service methods that call the command classes, and so on. I was wishing at the time that I could just say "here is my (new or changed) webservice - please adjust my code accordingly" through some GAT recipe.

Often a major change would be easier updated in teh code by going to the "Implements IMyChangingInterface" line in the class code (that has the blue squiggly line under it) and pressing Enter so that VB's Intellisense would create all the method stubs with the Implements IMyChangingInterface.YaddaYadda stuff on it, then move that method header to the "old" one and replace it. Then mess with the internal method code to deal with the new parameters.

The alternative I am thinking is to program the concrete class first, use it everywhere, and then have the factoring tools extract the Interface at the end (or at least when the code churn settles down) - however, I think there are advantages to using the Interfaces early - testing, for example, can be better factored early on by using interfaces. And if you leave the Interface extraction until later, how do you decide where you want to use the interface?

Ideally, I think I'd like a code tool that allows me to synch up a concrete class with its interface - but let it be a two-way synch if I want it, and be smart about identifying the method signatures that should get updated and where. Like Red-Gate's SQL-Compare, for example.

Ok, if I had any spare time, I'd dig into the GAT stuff and write those two recipes - synching a concrete class with an Interface, and updating the web service proxy command and service classes with an updated WSDL.

I still think I would use Interfaces, one way or another, but I do understand Sijin's pain around them.