Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "John B. Matthews" Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Thu, 12 May 2011 00:51:30 -0400 Organization: The Wasteland Lines: 68 Message-ID: References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <2psjssq4zj.fsf@shell.xmission.com> <2poc3gq3p2.fsf@shell.xmission.com> NNTP-Posting-Host: LQJtZWzu+iKlBROuDg+IUg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4000 In article , Daniele Futtorovic wrote: > On 11/05/2011 22:42, Lew allegedly wrote: > > 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. > > Not sure about "type". To me this "to the interface/contract" is a > step on the path towards hypothetical minimalism and good > definitions. Good definitions are a Good Thing not only for types, > but also for components, layers and applications as a whole. But > they're different /sorts/ of definitions for each level. > > > 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. > > _Ada_, mayhap? Ada [1]? It's not impossible, but the zealotry reminds me more of Eiffel [2], which includes particular support for design by contract [3]. Lew's notion of "program to the type" reminds me of the concept of abstract data type [4], which is well supported by Ada's notion of specification (package interface) and consistent with Patricia's Meaning 1. [1] [2] [3] [4] -- John B. Matthews trashgod at gmail dot com