Question

In a SO question on interface programming a commenter says –

Most answers to this question have the common misconception that
“programming to an interface” means use the interface language
construct; which is totally wrong! This is the first answer I’ve seen
that correctly illustrates that “programming to an interface” means:
don’t unnecessarily bind your ‘client code’ to concrete/specific
subclass implementations because if you later decide to change it use
a different implementation, you have a lot more work undoing all the
unnecessary bindings. I.e. program to/bind to things without
implementation details. E.g. Abstract base classes.;)

Can some please expand on this point, preferably in relation to c#.

Answer 1

My interpretation is that the answer is just expanding the notion of “interface” to mean binding to any set of properties and methods whether a “pure” interface (i.e. an interface in C#) or binding to a particular implementation. The answer’s point was that you could consider a class an “interface” by itself, and so you should program to the lowest base class that is necessary for your usage (a generic List contract versus a more specific ArrayList contract is that example).

You see this a lot in System.IO classes that bind to an abstract TextReader class versus an (non-existent) ITextReader interface.