[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

bridge design

ma740988

12/3/2008 3:50:00 AM


Consider:

#include <iostream>

struct data {
char c ;
int i ;
// more stuff
data ()
: c ( 0 )
, i ( 0 )
{}
};
class bar {
data dobj ;
public :
void set_bar ( data& d ) {
dobj = d ;
std::cout << dobj.i << std::endl;
}
void reset_bar () {
dobj = data() ;
}
};
// lots more class foo .. class that, class etc. etc. etc.
class bridge {
bridge() {}
bar b ;
// lots more
public:
static bridge& instance() {
static bridge obj ;
return obj;
}
bar& get_b() { return b; }
// lots more foo& get_foo() { return f; }
// etc. etc.
};

int main() {
data d ;
d.i = 5;
foo::instance().get_b().set_bar ( d );
std::cin.get();
}

The bar class is one example of a litany of classes that gets
instantiated within the bridge. I've perused a handful of information
online and I don't believe the code above is representative of the
bridge pattern. My colleague disagrees. Trouble is, I'm not sure
how to restructure source to use reflect the intent of the bridge
pattern.

Thoughts welcome.

Thanks
2 Answers

Michael DOUBEZ

12/3/2008 8:35:00 AM

0

ma740988 a écrit :
> Consider:
>
> #include <iostream>
>
> struct data {
> char c ;
> int i ;
> // more stuff
> data ()
> : c ( 0 )
> , i ( 0 )
> {}
> };
> class bar {
> data dobj ;
> public :
> void set_bar ( data& d ) {
> dobj = d ;
> std::cout << dobj.i << std::endl;
> }
> void reset_bar () {
> dobj = data() ;
> }
> };
> // lots more class foo .. class that, class etc. etc. etc.
> class bridge {
> bridge() {}
> bar b ;
> // lots more
> public:
> static bridge& instance() {
> static bridge obj ;
> return obj;
> }
> bar& get_b() { return b; }
> // lots more foo& get_foo() { return f; }
> // etc. etc.
> };
>
> int main() {
> data d ;
> d.i = 5;
> foo::instance().get_b().set_bar ( d );
> std::cin.get();
> }
>
> The bar class is one example of a litany of classes that gets
> instantiated within the bridge. I've perused a handful of information
> online and I don't believe the code above is representative of the
> bridge pattern. My colleague disagrees. Trouble is, I'm not sure
> how to restructure source to use reflect the intent of the bridge
> pattern.

IMO you are right. The intent is to decouple implementation from
interface, the idiom is similar to the pimpl:

class bridge {
//same as your exemple
//bridge delagate function to member
void set_bar( data& d ){b.set_bar(d);}
void reset_bar(){b.reset_bar();}
};

and in your main, you can treat the bridge as a bar:
data d ;
d.i = 5;
//foo::instance() can be a bridge or a bar
foo::instance().set_bar ( d );

Usually, bridge would contains a pointer to bar rather than a member in
order to remove the dependency with bar's implementation.

--
Michael

Daniel T.

12/3/2008 2:03:00 PM

0

In article <493642c5$0$32036$426a74cc@news.free.fr>,
Michael DOUBEZ <michael.doubez@free.fr> wrote:

> ma740988 a écrit :
> > Consider:
> >
> > #include <iostream>
> >
> > struct data {
> > char c ;
> > int i ;
> > // more stuff
> > data ()
> > : c ( 0 )
> > , i ( 0 )
> > {}
> > };
> > class bar {
> > data dobj ;
> > public :
> > void set_bar ( data& d ) {
> > dobj = d ;
> > std::cout << dobj.i << std::endl;
> > }
> > void reset_bar () {
> > dobj = data() ;
> > }
> > };
> > // lots more class foo .. class that, class etc. etc. etc.
> > class bridge {
> > bridge() {}
> > bar b ;
> > // lots more
> > public:
> > static bridge& instance() {
> > static bridge obj ;
> > return obj;
> > }
> > bar& get_b() { return b; }
> > // lots more foo& get_foo() { return f; }
> > // etc. etc.
> > };
> >
> > int main() {
> > data d ;
> > d.i = 5;
> > foo::instance().get_b().set_bar ( d );
> > std::cin.get();
> > }
> >
> > The bar class is one example of a litany of classes that gets
> > instantiated within the bridge. I've perused a handful of information
> > online and I don't believe the code above is representative of the
> > bridge pattern. My colleague disagrees. Trouble is, I'm not sure
> > how to restructure source to use reflect the intent of the bridge
> > pattern.
>
> IMO you are right. The intent is to decouple implementation from
> interface, the idiom is similar to the pimpl:
>
> class bridge {
> //same as your exemple
> //bridge delagate function to member
> void set_bar( data& d ){b.set_bar(d);}
> void reset_bar(){b.reset_bar();}
> };
>
> and in your main, you can treat the bridge as a bar:
> data d ;
> d.i = 5;
> //foo::instance() can be a bridge or a bar
> foo::instance().set_bar ( d );
>
> Usually, bridge would contains a pointer to bar rather than a member in
> order to remove the dependency with bar's implementation.

I agree with Michael with the caveat that the last line should be
"bridge::instance().set_bar( d );" :-)

One of the basic points of the bridge pattern is to disconnect the
implementation of a class from its interface. The OPs original code does
nothing of the kind.