Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!zarmer
From: zarmer@hplabsz.HPL.HP.COM (Craig Zarmer)
Newsgroups: comp.lang.c++
Subject: Wrapping inheritance hierarchies
Keywords: inheritance
Message-ID: <3959@hplabsz.HPL.HP.COM>
Date: 15 Sep 89 06:13:38 GMT
Organization: Hewlett-Packard Laboratories
Lines: 83


I have a question about the proper use of inheritance in C++ 2.0.  I'm
using InterViews, a C++ class library for building user interfaces,
but I think my question extends to any use of an aquired class
hierarchy.  I'm trying to 'wrap' the window class hierarchy in
InterViews to add some extra functionality.  Though in the case of
InterViews I have source and could just hack the root class, I'd
prefer not too, and in the general case we usually don't get source.

As an example, take the following InterViews classes:

class Interactor {public virtual void Draw(); ...};
class PushButton : public Interactor {...};
class ScrollBar : public Interactor {...};

In my own world I have

class ApplicObject {...};

I want to add a public member
  ApplicObject *subject
to all Interactors.  I then need a type or types that will allow me to
generically access subject and any public member of Interactor.

Schemes that don't work at all:

1) Add a new class SubjectView that contains an ApplicObject* and
make Interactor inherit from it.  This would only work if I had InterViews
source, which I'm pretending I don't.  

2) Create a subclass of every interesting Interactor and add
subject.  This leaves me with no generic way to reference subject.

3) Create a class SubjectView, and create subclasses of every
interesting Interactor by inheriting both from the Interactor subclass
and SubjectView.  I.e.

class SubjectView {public: ApplicObject *subject;};
class MyPushButton : public PushButton, public SubjectView {...};

This gives me generic access to both InterViews and subject, but not
at the same time.  There is no way to coerce from SubjectView* to
Interactor*, and I need to be able to Draw() and access subject.

4) Create SubjectView as above, then create a dummy class inheriting
from SubjectView and Interactor to get a common type, then create
subclasses inheriting from the common type and InterViews subclasses:

class SubjectView {public: ApplicObject *subject;};
class SubjectInteractor : public SubjectView, public Interactor {};
class MyPushButton : public PushButton, public SubjectInteractor {};

This is real close, but MyPushButton will get 2 Interactors.  Since I
don't have source, I can't make Interview's PushButton inherit
virtually from Interactor.


Ugly schemes that sort-of work:

5) Define SubjectView:

class SubjectView { 
public:
  ApplicObject *subject;
  Interactor *view;
...};

Make subclasses of Interactor classes that inherit from SubjectView
too and in their constructors, have them set view to themselves.  In
other words, give Mom a pointer to Dad via the Child.

6) Forget inheritance; make SubjectView a wholy separate class.  Use a
hash table to get the relation from Interactors to SubjectViews.


Since most companies that develop libraries for sale will not release
source, this scenario seems rather common.  Is there a proper way to
take in a class library and wrap all of the classes with some extra
functionality? 

Thanks,
Craig Zarmer
zarmer@hplabs.hp.com