Do use abstract (MustInherit in Visual Basic) classes instead of interfaces to decouple the contract from implementations.
The above is from "Type design guideline" by Microsoft. I am a bit confused about this. I always thought interfaces decoupled the contract from implementation. What exactly does the above guideline mean ?
Thanks
Both Abstract classes and Interfaces can "decouple the contract from implementations". In an abstract class, methods can be declared as abstract, without implementation, as when using an interface. For such methods, the dervived class must provide a Override method with an implementation, as when using an interface.
The differences between an abstract class and an interface is that an abstract class can contain some members that do have an implementation, which would then be shared among all derived classes, and it can contain private / protected fields ("state"), which an interface obviously cannot.
I think it's literally what it says. If you want to decouple contract from implementation, they're suggesting you use abstract classes instead of interfaces.
The suggestion I understand they're making is that you use interfaces when you need polymorphism related to custom value types, or if you want multiple inheritance, or because a type will have a large number of implementers. IDisposable for example is often inherited alongside multiple other interfaces, and IDisposable is implemented by a very large number of different classes so it makes sense as an interface by their rules.
If your contract isn't going to be implemented alongside other contracts, and it will be implemented by 8 or 10 diferent members, then an abstract class makes sense by the way I'm reading this.
Interfaces do decouple contracts from implementation. The type design guidelines you cite don't mean that interfaces are poor for decoupling contracts from implementation - what it means is that interfaces have additional restrictions that abstract classes don't have, so if you have a choice, these guidelines are suggesting you lean toward defining abstract classes when you want to define a contract without implementation instead of automatically defining an interface.
When designing a contract for use within an application, this is probably fair advice. However, interfaces have a distinct advantage if the contract will be used outside of your application, such as out of process calls via COM or .NET remoting, or across different languages (outside of .NET). When you need absolute isolation and independence of implementation, interfaces are better than abstract classes. For convenience and long term flexibility within your application (and when the absolute isolation of interfaces are not required), the guidelines recommend you can use abstract classes instead of interfaces.
The wording of the guidelines is partly a reflection of the fact that people tend to overuse interfaces, which can lead to unnecessary clutter and redundant implementation code.