bridge design

[ma740988]

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

 

[Michael DOUBEZ]

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.