Bridge patterns and protected inheritance?

  • Follow


Hi,
   I have a question regarding the use of the Bridge design pattern.
In particular, it has been suggested to me that the pattern be
implemented using protected inheritance of the handle by the body.  The
justifications given for this are 1) hide the existance of the body
class from the clients and 2) public inheritance is not appropriate
because a "isa" relationship does not exist between handle and body,
but an "is implemented in terms of" relationship makes sense.  Then,
once this basic structure is put in place, derived handle classes are
publicly inherited from the base handle class and, similarly, derived
body classes are publicly inherited from the base body class.
   So, a class hierarchy would look something like this:

class base_handle { /* ... */ }
class base_body : protected base_handle { /* ... */ }
class derived_handle : public base_handle { /* ... */ }
class derived_body : public base_body { /* ... */ }

   Okay, getting a little deeper, let's say that we wanted to enforce
the rule whereby clients are restricted from instantiating body
classes.  Then, one way to do this is to make the constructors in the
body classes protected, and make the handle class a friend of the body
class... something like this...

class base_handle
{
private:
   base_body * _body;
....
}

class base_body : protected base_handle
{
   friend class base_handle;
protected:
   base_body();
   base_body& base_body(const base_body& src);
   virtual ~base_body();
....
}

So, here's the question... has ANYONE ever seen an actual
implementation of the bridge pattern with this structure?  And,
regardless of whether or not it has been seen, I'd like to know your
thoughts on the issues that would be involved with such an
implementation.

Thanks, and best regards,

MPK


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply mark.kust (2) 9/21/2005 4:44:40 PM

On 09/21/2005 11:44 AM, MPK wrote:
[snip]
>    So, a class hierarchy would look something like this:
> 
> class base_handle { /* ... */ }
> class base_body : protected base_handle { /* ... */ }
> class derived_handle : public base_handle { /* ... */ }
> class derived_body : public base_body { /* ... */ }
[snip]
> the rule whereby clients are restricted from instantiating body
> classes.  Then, one way to do this is to make the constructors in the
> body classes protected, and make the handle class a friend of the body
> class... something like this...
> 
> class base_handle
> {
> private:
>    base_body * _body;
> ...
> }
> 
> class base_body : protected base_handle
> {
>    friend class base_handle;
> protected:
>    base_body();
>    base_body& base_body(const base_body& src);
>    virtual ~base_body();
> ...
> }
> 
> So, here's the question... has ANYONE ever seen an actual
> implementation of the bridge pattern with this structure?  And,
> regardless of whether or not it has been seen, I'd like to know your
> thoughts on the issues that would be involved with such an
> implementation.

I've seen something similar to implement the abstract syntax
tree for a compiler and to represent the grammar for the language
to be compiled.  The handles were refcounted smart pointers.
Your base_body corresponds to:

   class rTreeAbs : public iVirDtor{...};

where iVirDtor simply was had a virtual destructor and a reference 
count. Your base_handle correspoinds to:

  class rTreeAbs
  ;
  class hTreeAbs : public iVhandle{...};

where iVhandle is simply a handle ( actually a refence counted smart 
pointer) to iVirDtor*.

For example, the base grammar expression class was declared as:

   class rGramExpBase
: public rTreeAbs
  ...
  // Purpose:
  //   Provide a "representation" class for syntax tree nodes.
  //   Instances of this representation class will be
  //   handled by "handle" classes derived from hGramExpBase.
  {
  friend class hGramExpBase;

  ...
  };

where, of course, hGramExpBase was the corresponding handle
class.

It was about 10 years ago; hence, I can't remember much about
the issues other than being careful about cycles which
the refcounting couldn't collect.

HTH.

-regards,
Larry

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Larry 9/22/2005 8:57:39 AM


1 Replies
308 Views

(page loaded in 0.032 seconds)

Similiar Articles:











7/22/2012 7:55:42 PM


Reply: