From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/08/28 Message-ID: #1/1 X-Deja-AN: 268685633 Sender: news@inmet.camb.inmet.com (USENET news) References: <34046FAD.52BFA1D7@eiffel.com> Followup-To: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel X-Nntp-Posting-Host: houdini.camb.inmet.com Organization: Intermetrics, Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-28T00:00:00+00:00 List-Id: Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote: : Here is the reasoning behind the Eiffel approach to : separating interface from implementation. It was designed : in full knowledge of the Modula-2/Ada-83 mechanisms, in an : attempt to draw the lessons of both their advantages and : limitations, taking advantage of newer software technology : and of O-O principles... In my experience, separating the spec and body physically is extremely advantageous, and the need to have redundancy between the spec and body is an important feature in a multi-person project, not an "inconvenience." In Ada (and to some extent in C/C++ when you use header files in a disciplined way), changing the interface to a public routine, or adding a new public routine, or removing one, is a fundamentally different kind of operation, and *intentionally* requires more effort and care. : ... : G5. Minimize the programmer's work. In particular : it is crucial to avoid forcing the programmer : to duplicate text. Duplication is almost always : bad, especially with respect to ease of maintenance, : one of the central goals of software engineering. : It also hampers reuse, reliability (when you : duplicate code, you duplicate its bugs, and : the more software you write the more likely : it is that it will include bugs), and ease : of change. Basically, this is the paragraph I don't agree with, since the "duplication" one is talking about is duplication of the parameter/result/constraint profile in the spec and body of a package/class. The compiler checks for conformance, so the issue of forgetting to fix bugs in all copies doesn't arise. The compiler catches such gaffes. On the other hand, duplicating a chunk of algorithmic code in two places is undeniably bad news. But we aren't talking about that here. The programmer's work spent duplicating the interface in the spec and body is truly trivial, whereas the advantages of having a physically separate interface are profound in a multi-person (or just long-lived) project. I can believe this is somewhat just a matter of personal taste, and where one believes programmers should put their energy. However, there are some interesting anecdotes about programmers who go from a language like Fortran or old-style C where there is often no separate spec, to a language like Ada or Modula with physical separation. They suddenly realize that the spec is itself an important design object, something for potential users and implementors of an abstraction to work on together early in a project, and something which will allow users and implementors of the abstraction to go off and work relatively independently once agreement on the spec is reached. It becomes very clear that the spec is not "owned" by either the users or the implementors, but is rather the contract between them which will thereafter change only through collaborative renegotiation. : -- : Bertrand Meyer, President, ISE Inc. : ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 : 805-685-1006, fax 805-685-6869, : http://www.eiffel.com, with instructions for download -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA