Re: "Program to an interface" - When to break a design pattern
Daniele Futtorovic wrote:
Patricia Shanahan allegedly wrote:
I think some of the trouble might lie in the ambiguity, in a Java
context, of the sentence "Program to an interface.".
Meaning 1: Users of some module (in the widest sense) should depend only
on what is declared and specified about the module, not on direct
knowledge of how it is currently implemented.
Meaning 2: Java programs should depend only in Java interface types to
represent what is declared and specified about a module for the use of
its callers.
I am very strongly in favor of meaning 1 of "Program to an interface.".
Everything any user of a module needs to know about it should be
declared and/or specified as part of its interface (in the general
sense), and using code should depend only on what is declared and
specified.
Absolutely. Isn't the wording "program to a contract rather to an
implementation" also in use? I find that a much better one, because it doesn't
evoke Java interfaces.
I like the notion "program to the type". This subsumes Java interfaces and
classes, allows intelligent use of generics (which augment Java interfaces
just beautifully) to make type assertions, and incorporates the notion of
programming to a contract. It also allows the type to be 'LinkedHashMap'
where that is the type whose contract you actually need.
I have run into serious pushback from people who have a religion about
contract-based programming and a very different idea from me about who should
enforce what parts of a given contract. I don't remember which
Received-From-On-High placebo, er, miracle language they were touting - it's
famous but I don't care so I forget - that allowed them to be just as dogmatic
about "contract" as some in Java are about "interface", but their flavor of
fundamentalism was no improvement. One One True Way's proselyte is just as
crappy and obnoxious as every other One True Way's.
--
Lew
Never generalize.