Talk:Bridge pattern

From Wikipedia, the free encyclopedia

Even with the example, this article is impenetrable. Some of the problem may just be bad grammar/phrasing, but since I don't understand what it's trying to say I can't fix it myself. 18.24.0.120 04:23, 4 Dec 2003 (UTC)

The diagram and the accompaning Java code do not match. According to the code the arrow from Abstraction to Implementor is actually from RefinedAbstraction to Implementor.

[edit] C++

Sample for C++ bridge pattern is missing.

[edit] Code Added for C++

Added code for C++ but als also derived another class from the Abstraction to demonstrate the interchangebility - the main purpose of this Design Pattern. For the C++ code, the aggregate from Abstraction to Implementor is correct. The code for C# and Java isn't (July 11th, 2006).

Vladimir Bosnjak 10:12, 12 July 2006 (UTC)

[edit] C# Code now compiles

Made the C# code compilable, aggregate still incorrect.

[edit] Removed comment on C++ implementation

Somebody added a line that the C++ code isn't the bridge pattern. It sure is - only more efficiënt implemented. The poster/editor noted that a variable is "pushed up" (whatever that means). Please note that I implemented more abstract abstractions. That's what abstract classes are for! Please, next time, start a tech discussion first before editing the related wiki-page. Vladimir Bosnjak 18:45, 22 September 2006 (UTC)

[edit] What Needs To Be Done?

This article still seems to be too technical. That might be the case easely indeed for some or many. -->>What exactly needs to be done to make it more accessible? I could add a non-software image to visualize the "car example". I could add even more images, refining the steps. I could do a lot more in general. First of all I'd like to see a quick tutorial on how to add images to a wiki page. If someone is willing, please move to my talk-page and help me out with that part. Currently the "wiki manual" on this subject is overwhelming. My time is limited I'm affraid to read it all. I believe a detailed explanation on the details (e.g. code) is out of place. Yet I do agree that more detailed explanation is required. However, this needs teamwork. More insights on that later. Vladimir Bosnjak 20:15, 22 September 2006 (UTC)Vladimir Bosnjak 20:07, 22 September 2006 (UTC)

[edit] Does the Shape example at all justify the Bridge Pattern

I find it difficult to see the light when it comes to the Bridge Pattern. The most common example I see is the Shape example which is also used here. I can easily understand the example, but I find the solution using the Bridge Pattern complete silly.

Using the Bridge Pattern each shape instance is tied to a certain Drawing API. But that seems silly to me; why should shapes be bound to a media at all?

Many places including here the Bridge Pattern is related to working on several operating systems. But can you imagine that some of the shapes in a single running instance of program is on one operating system while others are on another operating system? I cannot, and therefore it seems strange that each shape should have an individual member signifying the operating system (using a Singleton pattern containg a strategy (cf. Strategy Pattern) seems more appropriate in this case).

If facing the problem of drawing using several different APIs in a single running instance of a program. I would use a different pattern (don't know if it has a name). Instead of tying each shape to a drawing API, I would supply the Drawing API to the draw operation. Using the C++ example the main code would look like this:

//The Client.
// -->> int main() merely demonstrates the interchangebility.
int main()
{
  Shape* TheShape[4]; //2 shapes x 2 implementations = 4 client-options.
  DrawingAPI* DA[2]; //2 Implementations.
  DA[0] = new OpenGL;
  DA[1] = new DirectX;


  TheShape[0] = new Circle(1, 2, 7.5);
  TheShape[0]->Draw(DA[0]);  //Draw circle with OpenGL


  TheShape[1] = new Circle(5, 7, 27.5);
  TheShape[1]->Draw(DA[1]); //Draw circle with DirectX


  TheShape[2] = new Square(10, 14);
  TheShape[2]->Draw(DA[0]);  //Draw square with OpenGL


  TheShape[3] = new Square(2.9, 80);
  TheShape[3]->Draw(DA[1]); //Draw square with DirectX


  //Give back allocated memory.
  delete DA[0], DA[1];
  delete TheShape[0], TheShape[1], TheShape[2], TheShape[3];


  return 0;
}

Another reason that this makes more sense is that the "Drawing API" in this case could also represent the media, so that you can draw the same shapes in several windows and on a printer, etc.

While I beleive I understand the Bridge Pattern, I still lack an example that justifies its use.

Thomas Linder Puls, Prolog Development Center, Denmark

One can't say. No real analysis has been provided to start with. But I don't believe the requirement as defined in the article (multiple shapes interchanged with multiple API's) is a good practical example. I agree with you on that. Interchanging shapes with devices (windows, forms, printers etc.) is a much better example.

I think that the one and only strength of this pattern lies in it's ability to demonstrate how multiple objects can be mixed the object oriented way. When I start to think hard, I too have problems finding the right example. If a good (realistic) example has been found, then the next question is: would the less experianced coder understand?

Vladimir Bosnjak 22:49, 23 November 2006 (UTC)