This is a second portion of my comments on the “Framework Design Guidelines” book. See also Part I. This post is devoted to the following recommendation we find on page 81 of the book:

DO favor defining (abstract) classes over interfaces

This is an often quoted guideline, that can be found in MSDN and elsewhere. It is probably the most controversial guideline in the book, especially given its near-mandatory strength (“DO”) as opposed to more lenient “CONSIDER”. The book itself contains descending opinions ranging from “I agree in general, but…” (Jeffrey Richter) to “you can see interfaces coming back” (Chris Anderson).

The author demonstrates this guideline on an example of the Stream class. “The System.IO.Stream abstract class shipped in version 1.0 of the framework without any support of timing out pending I/O operations. In version 2.0, several members were added to
Stream to allow subclasses to support timeout-related operations.”

public abstract class Stream
{
    public virtual bool CanTimeout { get { return false; } }

    public virtual int ReadTimeout
        { get { throw new NotSupportedException(); } }
        { set { throw new NotSupportedException(); } }
}