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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/03/28 Message-ID: #1/1 X-Deja-AN: 144600154 sender: news@assip.csasyd.oz references: <4ja50o$gup@inferno.mpx.com.au> organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-03-28T00:00:00+00:00 List-Id: Thomas, Hi! You wrote: :In article , donh@syd.csa.com.au (Don Harrison) writes: :>Norman H. Cohen wrote: :> :>:When Don Harrison asked how to achieve selective export in Ada, I :>:proposed a technique, but I never asked why one would want selective :>:export. :>: :>:Selective export does indeed help document the modular structure of a :>:program, and make the program easier for a reader to understand, but it :>:seems to me that the documentation is in the wrong place. In general, :>:the writer of a program component should be as unaware as possible of the :>:context in which that component will be used, especially if loose :>:coupling and reusability are valued. :> : :This area may seem initially to be one where Eiffel takes the wrong :tack. But consider two things: : :a) we shouldn't be obsessed with single-class encapsulation at the : expense of allowing coarse-grained objects consisting of : collaborating fine-grained instances. Such coarse-grained entities : represent closely co-operating and "co-designed" abstractions; for : example most design patterns and small software components would : fall into this category. I would suggest that the really important : boundary of re-use is not around the single class, but around small : groups of classes designed to realise a coarser abstraction. Wouldn't structuring depend on whether or not the behaviour is self contained or not? Consider each case: 1) Self contained - we would then want to wrap the co-operating abstractions into a higher level abstraction, perhaps using a deferred class with constrained generic parameters. Then the design would offer a single cohesive interface for easy reuse. 2) Not self contained - the co-operating abstractions are linked to other abstractions so may not be encapsulated. Would this indicate a design flaw? It would certainly make reuse more difficult. Which one corresponds to design patterns? Both? :b) the Eiffel export mechanism can be used to specify an abstract : parent class e.g. : : feature {LIST} : : This effectively says that any class conforming to the design : intention of LIST may have access to the following features. Thus : selective export does not restrict the client to be a single : effective class, but to classes conforming to a design idea. So, LIST would be 'deferred' in this case? [Eiffel analogue of 'abstract']. :- Thomas Beale : :____________________________________________________________________________ :Thomas Beale | : Class Technology | Email: thomas@class.com.au : PO Box 6274 North Sydney | : NSW 2060 | Ph: +61 2 9922 7222 : AUSTRALIA | Fax: +61 2 9922 7703 :_______________________________________|____________________________________ Don.