By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,205 Members | 1,116 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,205 IT Pros & Developers. It's quick & easy.

Bridge pattern? What is the use?

P: n/a
The code below was taken from an example.
All the "noise" in the example was thrown out.
This is supposedly according to the bridge
pattern. What in the code (which lines)
represent the bridge pattern (make this code
to be according to the bridge pattern),
and what is the advantage of employing the
bridge pattern? It seems "l'art pour l'art" to me.

Adrian

using System.Collections;

namespace trial_seven
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();
customers.show();
}

class CustomersBase
{
private DataObject dataObject;
protected string group;
public CustomersBase(string group)
{
this.group = group;
}

public DataObject Data
{
set
{
dataObject = value;
}
get
{
return dataObject;
}
}

public virtual void show()
{
dataObject.ShowRecord();
}
}

class Customers:CustomersBase
{
public Customers (string group):base(group)
{
}
}

abstract class DataObject
{
public abstract void ShowRecord();
}

class CustomersData:DataObject
{
private ArrayList customers = new ArrayList();
private static int current = 0;

public CustomersData()
{
customers.Add("Jim Jones");
customers.Add("Frank Rapper");
}
public override void ShowRecord()
{
Console.WriteLine(customers[current++]);
}
}
}
}
Oct 11 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Adrian wrote:
The code below was taken from an example.
All the "noise" in the example was thrown out.
This is supposedly according to the bridge
pattern. What in the code (which lines)
represent the bridge pattern (make this code
to be according to the bridge pattern),
and what is the advantage of employing the
bridge pattern? It seems "l'art pour l'art" to me.

Adrian

using System.Collections;

namespace trial_seven
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();
customers.show();
}

class CustomersBase
{
private DataObject dataObject;
protected string group;
public CustomersBase(string group)
{
this.group = group;
}

public DataObject Data
{
set
{
dataObject = value;
}
get
{
return dataObject;
}
}

public virtual void show()
{
dataObject.ShowRecord();
}
}

class Customers:CustomersBase
{
public Customers (string group):base(group)
{
}
}

abstract class DataObject
{
public abstract void ShowRecord();
}

class CustomersData:DataObject
{
private ArrayList customers = new ArrayList();
private static int current = 0;

public CustomersData()
{
customers.Add("Jim Jones");
customers.Add("Frank Rapper");
}
public override void ShowRecord()
{
Console.WriteLine(customers[current++]);
}
}
}
}
Oct 11 '06 #2

P: n/a
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern
Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?

Oct 11 '06 #3

P: n/a
Not the easiest pattern to get your head around, but this article
explains it pretty well:
http://www.codeproject.com/gen/design/bridge.asp

Adrian wrote:
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern
Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?
Oct 11 '06 #4

P: n/a
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods than the associated Data object.

Its useage might be even clearer if you look at a method that takes a parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
>l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern
Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?

Oct 11 '06 #5

P: n/a
Is using abstract and concrete classes (decoupling)
for hiding the concrete classes from users? If not,
why is it done?

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods than
the associated Data object.
>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern
Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?



Oct 11 '06 #6

P: n/a
Hi Adrian,

Exactly. By using an abstract class you can swap out the implementation in the caller whenever you need to refactor your code and
it enables your code to be dynamic enough when you need to vary implementations at runtime. The consumer of the class doesn't need
to be aware of the implemention, it just needs a reference to the interface (abstract class in this case).

Be aware when using patterns that decouple implemention by using polymorphism that if you see something like the following you
should probably invest your time in finding a more appropriate pattern to meet your needs:

public void ShowCustomerToUser(CustomerBase customer)
{
if (customer.GetType() == typeof(SpecialProcessCustomerData))
{
// we require a special process to occur first, in this case
customer.SpecialProcess();
}

// all customers may be "shown"
customer.show();
}

Hopefully you see the benefit of the bridge pattern and how it could be used to alleviate any need for the explicit Type check
above. The idea is to "abstract" the "ShowCustomerToUser" method from requiring a reference or any knowledge at all of the
implementation of the specified "customer" object.

public class SpecialProcessCustomerData : DataObject
{
public void show()
{
// TODO: special processing
// TODO: show something
}
}

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message news:45********************@dreader2.news.tiscali. nl...
Is using abstract and concrete classes (decoupling)
for hiding the concrete classes from users? If not,
why is it done?

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
>Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
>decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
>these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
>implementations would commonly have different, higher-level methods than
the associated Data object.
>>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
>of both the abstraction and decoupling of implementation is more apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?



Oct 11 '06 #7

P: n/a
In case of: / if you do as you suggest:
customers.Data = new PrimaryCustomersData();
customers.show();
customers[] isn't filled
and the appp errors out

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods than
the associated Data object.
>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern
Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?



Oct 11 '06 #8

P: n/a
By the way I did add on another child of DataObject.

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
In case of: / if you do as you suggest:
customers.Data = new PrimaryCustomersData();
customers.show();

customers[] isn't filled
and the appp errors out

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods than
the associated Data object.

Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more
apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
>l'art pour decoupler une abstraction de son execution ;)
>http://en.wikipedia.org/wiki/Bridge_pattern
>>
Yes that is where I got it from :(
>
"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?
>
>
>


Oct 11 '06 #9

P: n/a
Hi Adrian,

I'm not sure I understand what you mean. The app won't even compile because the PrimaryCustomersData class isn't defined. I was
just trying to illustrate a point: Being able to assign any implementation to the Data property is part of the flexibility provided
by the bridge pattern.

If you tried to compile the application after creating your own PrimaryCustomersData class then it's your implementation that is
failing.

Care to post your code?

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message news:45********************@dreader2.news.tiscali. nl...
In case of: / if you do as you suggest:
> customers.Data = new PrimaryCustomersData();
customers.show();

customers[] isn't filled
and the appp errors out

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
>Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
>decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
>these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
>implementations would commonly have different, higher-level methods than
the associated Data object.
>>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
>of both the abstraction and decoupling of implementation is more apparent:

public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?



Oct 11 '06 #10

P: n/a
Dave, I can see what you are getting at here. How the bridge pattern does a
better job
then polymorphism.

I have successfully implemented your suggestions to bear out the workings of
the example a bit better now.

Your remarks do a good job in explaining the know-why of the bridge pattern.

Unfortunately too often *only* know-how and know-when is explained.

Many thanks,
Adrian. (Nom de plume.)

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O2**************@TK2MSFTNGP05.phx.gbl...
Hi Adrian,

Exactly. By using an abstract class you can swap out the implementation
in the caller whenever you need to refactor your code and
it enables your code to be dynamic enough when you need to vary
implementations at runtime. The consumer of the class doesn't need
to be aware of the implemention, it just needs a reference to the
interface (abstract class in this case).
>
Be aware when using patterns that decouple implemention by using
polymorphism that if you see something like the following you
should probably invest your time in finding a more appropriate pattern to
meet your needs:
>
public void ShowCustomerToUser(CustomerBase customer)
{
if (customer.GetType() == typeof(SpecialProcessCustomerData))
{
// we require a special process to occur first, in this case
customer.SpecialProcess();
}

// all customers may be "shown"
customer.show();
}

Hopefully you see the benefit of the bridge pattern and how it could be
used to alleviate any need for the explicit Type check
above. The idea is to "abstract" the "ShowCustomerToUser" method from
requiring a reference or any knowledge at all of the
implementation of the specified "customer" object.

public class SpecialProcessCustomerData : DataObject
{
public void show()
{
// TODO: special processing
// TODO: show something
}
}

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
Is using abstract and concrete classes (decoupling)
for hiding the concrete classes from users? If not,
why is it done?

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods
than
the associated Data object.
>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more
apparent:
>
public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?




Oct 11 '06 #11

P: n/a
Dave, please see my other post to you.
Many thanks.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:eQ*************@TK2MSFTNGP03.phx.gbl...
Hi Adrian,

I'm not sure I understand what you mean. The app won't even compile
because the PrimaryCustomersData class isn't defined. I was
just trying to illustrate a point: Being able to assign any
implementation to the Data property is part of the flexibility provided
by the bridge pattern.

If you tried to compile the application after creating your own
PrimaryCustomersData class then it's your implementation that is
failing.

Care to post your code?

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
In case of: / if you do as you suggest:
customers.Data = new PrimaryCustomersData();
customers.show();
customers[] isn't filled
and the appp errors out

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods
than
the associated Data object.
>
Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more
apparent:
>
public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?




Oct 11 '06 #12

P: n/a
Hi Adrian,

Glad I could help.
Unfortunately too often *only* know-how and know-when is explained.
I agree, but books and in-depth articles usually fill in the blanks nicely.

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message news:45********************@dreader2.news.tiscali. nl...
Dave, I can see what you are getting at here. How the bridge pattern does a
better job
then polymorphism.

I have successfully implemented your suggestions to bear out the workings of
the example a bit better now.

Your remarks do a good job in explaining the know-why of the bridge pattern.

Unfortunately too often *only* know-how and know-when is explained.

Many thanks,
Adrian. (Nom de plume.)

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O2**************@TK2MSFTNGP05.phx.gbl...
>Hi Adrian,

Exactly. By using an abstract class you can swap out the implementation
in the caller whenever you need to refactor your code and
>it enables your code to be dynamic enough when you need to vary
implementations at runtime. The consumer of the class doesn't need
>to be aware of the implemention, it just needs a reference to the
interface (abstract class in this case).
>>
Be aware when using patterns that decouple implemention by using
polymorphism that if you see something like the following you
>should probably invest your time in finding a more appropriate pattern to
meet your needs:
>>
public void ShowCustomerToUser(CustomerBase customer)
{
if (customer.GetType() == typeof(SpecialProcessCustomerData))
{
// we require a special process to occur first, in this case
customer.SpecialProcess();
}

// all customers may be "shown"
customer.show();
}

Hopefully you see the benefit of the bridge pattern and how it could be
used to alleviate any need for the explicit Type check
>above. The idea is to "abstract" the "ShowCustomerToUser" method from
requiring a reference or any knowledge at all of the
>implementation of the specified "customer" object.

public class SpecialProcessCustomerData : DataObject
{
public void show()
{
// TODO: special processing
// TODO: show something
}
}

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
Is using abstract and concrete classes (decoupling)
for hiding the concrete classes from users? If not,
why is it done?

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP02.phx.gbl...
Hi Adrian,

Maybe this link will clear it up more for you:

G.O.F. on Bridge:
http://www.dofactory.com/Patterns/PatternBridge.aspx
I believe you have partially identified the bridge. The part that you
didn't acknowledge is the two abstract classes and the
decoupling of the implementation.

The GOF example is much clearer, IMO. Look at the C# code sample.

To equate their sample to your sample:

[STAThread]
static void Main(string[] args)
{
Customers customers = new Customers("Chicago");
customers.Data = new CustomersData();
customers.show();

customers.Data = new PrimaryCustomersData();
customers.show();

customers.Data = new SpecialProcessCustomersData();
customers.show();
}
Also, note that show can call multiple methods on the Data object if
necessary, so it doesn't have to simply be pass-thru as in
these examples. In that case the concrete CustomerBase implementation
acts as a facade as well. Also, concrete CustomerBase
implementations would commonly have different, higher-level methods
than
the associated Data object.

Its useage might be even clearer if you look at a method that takes a
parameter of type, "CustomerBase". In that case the benefit
of both the abstraction and decoupling of implementation is more
apparent:
>>
public void ShowCustomerToUser(CustomerBase customer)
{
customer.show();
}

HTH

--
Dave Sexton

"Adrian" <no*@all.accessiblewrote in message
news:45********************@dreader2.news.tiscali. nl...
"Chris Fulstow" <ch**********@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
l'art pour decoupler une abstraction de son execution ;)
http://en.wikipedia.org/wiki/Bridge_pattern

Yes that is where I got it from :(

"decoupler une abstraction de son execution"
That is happening twice in my perception,
but that doesn't seem to be specific for
what the code is purporting to represent,
namely a bridge. I could image show, called
in main, and, in turn, calling ShowRecord, to
be the bridge. But what is so useful about
doing that? Obfuscation or 3-tier stuff?





Oct 11 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.