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)

This article may be too technical for a general audience.
Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details.

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

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

Why is the c++ code too unnecessarily obfuscated. Why do we need to have a vector of shapes just to show how it works on 2 different types of circles. I don't think the reader cares about using iterators to traverse a container, he/she wants to see how to use the bridge pattern. Also, what is std::mem_fun and std::bind2nd doing here? and stdafx.h is not a standard header. They don't help show what a bridge is and also confuses a reader!
I have rewritten the code using the same ideas as all of the other ones. It is more readable.--Michael miceli (talk) 05:57, 6 April 2008 (UTC)


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

I recommend deleting the current "Car abstraction" example, as it is incorrect. A road is not an implementation of a car. For that matter, I would avoid using any automotive analogies here. Consider a real-world bridge-- i.e., a structure allowing a road (and therefore cars) to pass over an obstruction. This has little to do with the Bridge pattern, so examples involving cars and roads are likely to just confuse the reader. 14-JUN-2007 Mahler3 21:17, 15 June 2007 (UTC)

I tagged the example as being too confusing. I think it would make more sense if only two examples were given, instead of listing two, and then going into four or so examples with the overly complicated drawing api example. Car->Jaguar Car->Mercedes. Shape->Circle Shape->Square. --Odie5533 03:29, 2 August 2007 (UTC)

Nallap 11:54, 24 October 2007 (UTC)

[edit] Suggestions for changes for Car abstraction:

The Car example needs some changes as it does not explain the pattern practically. The change I would suggest is as follows.

Car is an abstraction and may be the refined abstraction of car can be Mercedes Make-I (e.g C-class) and Make-II (E-class).Then I totally disagree with Road as the implementation as it is too generic/amateuristic and not a very good real life example. I would suggest the actual implementation of the car can be Engine as it is the heart of any car. So refined implementation can be some thing like a Petrol Engine implementation and a diesel engine implementation. More refining can be done here something like 2-valve engine, 4,6,8 valve engines etc. Any feed back? Also this requires a total revamp of the examples in all languages. I can take care of C++ and C#. Let me know if this is OK.

[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)
I think the shape example indicates the Strategy Pattern much more than the Bridge. The Bridge is a good way of encapsulating differences when there are two independent axes of variation. It prevents an explosion of subclasses. Neither the car nor the shape example really shows this. 04 September 2007 —Preceding unsigned comment added by 216.99.6.9 (talk) 20:36, 4 September 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)
  • I think it's a good thing that there are a few different languages here. After all, this is a software engineering page. There's a diagram, some explanatory text and a few examples. Sounds perfectly good to me. Philomathoholic 08:50, 1 September 2007 (UTC)
  • I think the purpose of this article is to give explanation about the pattern. So, a single example may be sufficient to describe the purpose of it. If there is too much examples, the readers may get lost. For example, there is a reference in the beginning of the article about Visual Prolog, so the reader will need to read the Visual Prolog even if it has already read the Java example. Maybe only one example may be sufficient (with clean and easy syntax language). The other examples could be given in the external links. There is a lot of references out there. Edans 16:16, 1 September 2007 (UTC)

[edit] Deleted many examples

I deleted many of the examples. Erlang isn't that popular (yet)(according to wikipedia), and c#, c++, and java are industry standards and university standards. —Preceding unsigned comment added by Michael miceli (talk • contribs) 06:08, 6 April 2008 (UTC)

Commentary:

"c# and java are industry standards and university standards" which means that they are the most important. What you did is wrong (at least in this respect). —Preceding unsigned comment added by 195.72.132.1 (talk) 12:27, 5 May 2008 (UTC)