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.

Contents 1 C++ 2 Code Added for C++ 3 C# Code now compiles 4 Removed comment on C++ implementation 5 What Needs To Be Done? 6 Does the Shape example at all justify the Bridge Pattern 7 why are their a bunch of different code examples?

[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).

---

[[User:Vladimir Bosnjak|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)

Objects can be mixed the object oriented way very easily: just add pointers and methods (for an example see http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.5). Actually the so-called bridge pattern is one case of triviality and basic principles' violation that any newbie will start overexploiting the second month working as a C++ developer. Vladimir, I think the shape example is completely wrong: it violates encapsulation and abstraction and seriously mutilates inheritance. Shape should (really) be pure virtual and Drawcircle(), DrawSquare() and the like should be protected methods in the respective Shape subclasses. And of course data like radius should be private to the relevant classes. What does a square need a radius for? And of course you should have a method to set the drawingAPI pointer, otherwise it makes no sense, it is a huge roundabout just to make a few simple calls and introduce a lot of bugs ;-). Such a system could only draw circles and squares, but if you wanna draw a line you must touch all three classes, while if done correctly you merely need to add a line class. I believe you probably had in mind more complex subclasses of shape, such as "car" for example, which might need a number of calls to basic drawing api's. But again Thomas' way is of course correct and consistent with the sanity of OOP: the desired device context would be fed to the shape instance at run-time, so that it can call the api's functions directly.Dpser 13:18, 10 January 2007 (UTC)

The both of you are right but I am weary of using a device context in code examples because many students never used a device context before they're taught some basic patterns. However, I'm violating encapsulation and abstraction but I'm not motivated to do my best anymore because some lone ranger deletes C++ code because he thinks Java should be the standard. See my talk page. It takes way too many steps before some kind of justice is done. I may work a few hours on this topic only to see the next day the C++ code has dissapeared here as well... But make no mistake, I agree with both Dpser and Thomas and the C++ code should be corrected (encapsualation and abstraction violations). Le Comte Valmont 20:43, 22 February 2007 (UTC)

[edit] why are their a bunch of different code examples?

that's just retarded. Give one or two languages and leave it be. —The preceding unsigned comment was added by 169.231.11.44 (talk) 06:04, 27 February 2007 (UTC).

• You might be taken seriously if you gave a reason why there should not be examples in many languages. 35.9.26.55 04:35, 1 March 2007 (UTC)

• There are two problems with the examples. One is that there are two few of them. Why not C++? Why not Python? Why not Java? The other problem is exactly the opposite; there are too many of them. When you try to cover all bases, you end up with the main point of the article getting lost in the noise. I'm with the anonymous post above; just pick one or two representitive languages and let it go at that. Pick langages which are well known and/or easy to read without knowing the syntax details. -- RoySmith (talk) 14:10, 25 March 2007 (UTC)