🚀 go-pugleaf

chip@tct.com (Chip Salzenberg) writes:

>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.

Introducing "wrappers" has almost the same disadvantages than the
first method because it only solves an *isolated* problem and not the
"impedance mismatch".  A few points to consider are:

- Objects aren't in just one collection or used by just one subpart of
  the system.  Several subparts work with (partially overlapping)
  subinterfaces of your objects.  You may need different wrappers for
  the same object (with different type hierarchies).

- Besides being cumbersome to write (wasn't OOP supposed to reduce
  duplication and programming time?), wrappers create problems with
  object identity.

- Wrappers only work for "first-level" imports, i.e. when the
  subsystem that you're reusing gives you As and Bs rather than
  collection of As or Bs.  This is not a realistic assumption (or
  else you'd be reusing only low-level subsystems).


-Urs
-- 
------------------------------------------------------------------------------
Urs Hoelzle                                            hoelzle@cs.stanford.EDU
Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305