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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Matt Austern Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/11 Message-ID: #1/1 X-Deja-AN: 271625270 References: <34167245.0@news.uni-ulm.de> Organization: SGI Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-11T00:00:00+00:00 List-Id: doylep@ecf.toronto.edu (Patrick Doyle) writes: > Close, but IMO no cigar. If we are faithfully to compare Ada and > Eiffel ways of doing this, then just as an Ada package is accessed > through its interface, so would the Eiffel class be accessed only > through the abstract superclass. Thus, even if the subclass > added public features, the client couldn't use them. Except that that's impossible. You have to know the name of the derived class, and the signatures of its creation functions, in order to create objects of that class. So the interface of the derived class cannot be completely hidden. (Or, alternatively, you could have a third class, a "factory" class, that exists only to create instance of the derived implementation class. In that case, you could hide the derived class completely. Even so, though, you would have to know the interfaces of at least two classes; the abstract base class does not suffice. And note that Eiffel doesn't let you use this method for expanded classes or objects.) The bottom line: inheritance is useful for some purposes, but it is not a panacea. Base-derived semantics is not at all the same as interface-implementation semantics.