Interfaces, Abstract Classes, and Inversion of Dependency
In Framework Design Guidelines (Cwalina and Abrams, Addison-Wesley), the authors have a section in Chapter Four entitled "Choosing Between Class and Interface" that is very revealing about the "behind the scenes" goings on during the development of the .NET Framework. They say that in general, classes are the preferred construct for exposing abstractions, the logical basis of this being that once you ship an interface, the set of members is baked forever - any additions would break existing types that implement the interface. Classes are much more flexible - you can add members to classes that have already shipped, and as long as the method has a default implementation, existing derived classes continue to function undisturbed. They provide an example (although not a very good one) of how difficult it would be to add timeout support for streams. All of the options have substantial development cost and usability issues. It seems that one of the primary arguments for...