I think you’re overrusing interfaces.
Meyer and Martin told us: “Open for extension but closed for modification!”
and then Cwalina (et al) reiterated:
From Framework Design Guidelines…
In general, classes are the preferred
construct for exposing abstractions.
The main drawback of interfaces is
that they are much less flexible than
classes when it comes to allowing for
evolution of APIs. Once you ship an
interface, the set of its members is
fixed forever. Any additions to the
interface would break existing types
implementing the interface.
A class offers much more flexibility.
You can add members to classes that
have already shipped. As long as the
method is not abstract (i.e., as long
as you provide a default
implementation of the method), any
existing derived classes continue to
Ideally, you shouldn’t be changing your interfaces very often (if at all). If you do need to change an interface, you should reconsider its purpose and see if the original name still applies to it.
If you still feel that the interfaces will change, and the interfaces changes are small (adding items) and you have control of the whole code base, then you should just modify the interface and fix all the compilation errors.
If your change is a change in how the interface is to be used, then you need to create a separate interface (most likely with a different name) to support that alternative usage pattern.
Even if you end up creating ISomething, ISomething2 and ISomething3, the consumers of your interfaces will have a hard time figuring out what the differences are between the interfaces. When should they use ISomething2 and when should they use ISomething3? Then you have to go about the process of obsoleting ISomething and ISomething2.
I agree with Garo Yeriazarian, changing interface is a serious decision. Also, if you want to promote usage of new version of interface you should mark old version as obsolete. In .NET you can add ObsoleteAttribute.