Xref: utzoo comp.lang.misc:7228 comp.object:2997 comp.lang.eiffel:1483 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!pdn!tscs!tct!chip From: chip@tct.com (Chip Salzenberg) Newsgroups: comp.lang.misc,comp.object,comp.lang.eiffel Subject: Re: CHALLENGE: typing and reusability Message-ID: <27F77DEB.17DA@tct.com> Date: 1 Apr 91 18:37:30 GMT References: <1121@tetrauk.UUCP> <1991Mar31.215721.18687@neon.Stanford.EDU> Organization: Teltronics/TCT, Sarasota, FL Lines: 25 According to hoelzle@neon.Stanford.EDU (Urs Hoelzle): >Here's the scenario on which my claim is based: > >1) You haven't written A and B yourself but bought them from someone. > That is, you cannot change A or B to inherit from a common base > class. > > The solution to this is to subclass A and B (with classes SubA and > SubB) in order to define the necessary "interface glue". There is a better solution: Create an abstract GenericFoo class, which is the element type for the FooCollection. Then define subclasses of GenericFoo called FooA, FooB, etc. Here's the key part: each FooA _refers_ to an A, each FooB _refers_ to a B, etc. With this scheme, all member functions interesting to the collection (and the collection's clients) can be implemented as virtual functions defined in GenericFoo and implemented in all subclasses of GenericFoo. This alternative solves the problem of subclassing A and B, because FooA can refer as easily to a SubA as to an A. -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre