Talk:Bridge pattern

message: 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)
thread_title:  Code Added for C++ 

message: 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)
thread_title:  Removed comment on C++ implementation 

message: 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)
replies: text: 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)
thread_title:  What Needs To Be Done? 

message: 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.
==== 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;
 <BR>
   TheShape[0] = new Circle(1, 2, 7.5);
   TheShape[0]->Draw(DA[0]);  //Draw circle with OpenGL
 <BR>
   TheShape[1] = new Circle(5, 7, 27.5);
   TheShape[1]->Draw(DA[1]); //Draw circle with DirectX
 <BR>
   TheShape[2] = new Square(10, 14);
   TheShape[2]->Draw(DA[0]);  //Draw square with OpenGL
 <BR>
   TheShape[3] = new Square(2.9, 80);
   TheShape[3]->Draw(DA[1]); //Draw square with DirectX
 <BR>
   //Give back allocated memory.
   delete DA[0], DA[1];
   delete TheShape[0], TheShape[1], TheShape[2], TheShape[3];
 <BR>
   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)
replies: text:  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)
replies: text:  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)
replies: text:  Please read this Talk:Design pattern (computer science)# Extraneous Examples the guy wasn't ill intended. Your source code should be moved to wiki books, with a link here to wikibooks just like Singleton pattern --lexxdark (talk) 05:02, 28 May 2009 (UTC)

text: 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)
thread_title:  Suggestions for changes for Car abstraction: 

message: 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;
 <BR>
   TheShape[0] = new Circle(1, 2, 7.5);
   TheShape[0]->Draw(DA[0]);  //Draw circle with OpenGL
 <BR>
   TheShape[1] = new Circle(5, 7, 27.5);
   TheShape[1]->Draw(DA[1]); //Draw circle with DirectX
 <BR>
   TheShape[2] = new Square(10, 14);
   TheShape[2]->Draw(DA[0]);  //Draw square with OpenGL
 <BR>
   TheShape[3] = new Square(2.9, 80);
   TheShape[3]->Draw(DA[1]); //Draw square with DirectX
 <BR>
   //Give back allocated memory.
   delete DA[0], DA[1];
   delete TheShape[0], TheShape[1], TheShape[2], TheShape[3];
 <BR>
   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)
replies: text:  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)
replies: text:  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)
replies: text:  Please read this Talk:Design pattern (computer science)# Extraneous Examples the guy wasn't ill intended. Your source code should be moved to wiki books, with a link here to wikibooks just like Singleton pattern --lexxdark (talk) 05:02, 28 May 2009 (UTC)

text: 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)
thread_title:  Does the Shape example at all justify the Bridge Pattern 

message: 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)
thread_title:  why are their a bunch of different code examples? 

message: 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)
thread_title:  Deleted many examples 

message: The bridge pattern is useful when not only the class itself varies often, but the class does also
Is there a typo in there? It effectively says 'when not only X but also X'!  —Preceding unsigned comment added by 80.169.133.251 (talk) 10:47, 20 February 2009 (UTC)
thread_title:  Typo? 

message: I don't think there is a need for two Perl Moose examples so I moved this one to the discussion page. If there is more than one Perl example then one should probably use just core modules. Argel1200 (talk) 19:19, 12 August 2009 (UTC)
thread_title:  No need for two Perl examples 

message: I don't know if all the code examples are the same, but the C++ example code doesn't match the description.  The "maintains reference to the implementation" is in the wrong class, so it does not follow the pattern.
<BR>—Długosz (talk) 16:12, 9 March 2010 (UTC)
thread_title:  C++ example code doesn't match description 

message: What is the purpose for the IAbstractBridge inteface in the C# example? I see no techical or didactical reason for not just creating the AbstractBridge directly, with no interface. 5.23.32.98 (talk) 18:07, 13 January 2017 (UTC)
thread_title:  C# example 

message: The Bridge  
design pattern is one of the twenty-three well-known 
GoF design patterns 
that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
What problems can the Bridge design pattern solve? 
* An abstraction and its implementation should be defined and extended independently from each other.
* A compile-time binding between an abstraction and its implementation should be avoided so that an implementation can be selected at run-time.
When using subclassing, an implementation is selected at compile-time and can't be changed at run-time.
What solution does the Bridge design pattern describe? 
* Separate an abstraction (Abstraction) from its implementation (Implementor) by putting them in separate class hierarchies.
* Implement the Abstraction in terms of (by delegating to) an Implementor object.
This enables to configure an Abstraction with an Implementor object at run-time.
See also the UML class and sequence diagram below.
Vanderjoe (talk) 12:29, 1 September 2017 (UTC)
thread_title:  Overview 

message: I suggest that attention be drawn to the following:
* Abstract classes define an interface for concrete implementations to implement. This interface is all the abstract methods required to be implemented by the concrete implementations of the abstract class. ie. The implementor interface already exists as abstract methods in abstract classes that use inheritance rather than bridge/stategy pattern.
* Often, these abstract methods are not accessible to users, but are called by concrete methods of the abstract class. The implementor interface is different in purpose and use to the abstraction. Users of the abstraction don't need to be calling this interface directly. If we use abstract classes and inheritance rather than bridge/strategy, we combine two separate interfaces into one class - the abstraction interface that the user cares about and the implementor interface the user does not care about.
* The bridge and strategy patterns involve extracting the implementor interface into a separate class and using composition-over-inheritance in the abstraction, reducing the abstraction to only the abstraction interface the user cares about.
* The because of the use of composition-over-inheritance, the abstraction may often be converted into a concrete class.
Individual87981263 (talk) 11:35, 10 March 2020 (UTC)
thread_title:  Facilitates composition over inheritance and making abstraction concrete