Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Bridge pattern
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Design pattern used in software engineering}} The '''bridge pattern''' is a [[software design pattern|design pattern]] used in [[software engineering]] that is meant to ''"decouple an [[Abstraction (computer science)|abstraction]] from its [[implementation]] so that the two can vary independently"'', introduced by the [[Design Patterns|Gang of Four]].{{r|GoFp151}} The ''bridge'' uses [[encapsulation (computer science)|encapsulation]], [[Object composition#Aggregation|aggregation]], and can use [[inheritance (object-oriented programming)|inheritance]] to separate responsibilities into different [[Class (computer science)|classes]]. When a class varies often, the features of [[object-oriented programming]] become very useful because changes to a [[Computer program|program]]'s [[Source code|code]] can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class and what it does vary often. The class itself can be thought of as the ''abstraction'' and what the class can do as the ''implementation''. The bridge pattern can also be thought of as two layers of abstraction. When there is only one fixed implementation, this pattern is known as the [[Pimpl]] idiom in the [[C++]] world. The bridge pattern is often confused with the [[adapter pattern]], and is often implemented using the [[Adapter_pattern#Object_adapter_pattern|object adapter pattern]]; e.g., in the Java code below. Variant: The implementation can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized<!-- (as illustrated by the [[Visual Prolog]] example below)-->. == Overview == The Bridge design pattern is one of the twenty-three well-known ''[[Design Patterns|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.{{r|GoFp151}} What problems can the Bridge design pattern solve?<ref>{{cite web|title=The Bridge design pattern - Problem, Solution, and Applicability|url=http://w3sdesign.com/?gr=s02&ugr=proble|website=w3sDesign.com|access-date=2017-08-12}}</ref> * 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, different subclasses implement an abstract class in different ways. But an implementation is bound to the abstraction at compile-time and cannot be changed at run-time. What solution does the Bridge design pattern describe? * Separate an abstraction (<code>Abstraction</code>) from its implementation (<code>Implementor</code>) by putting them in separate class hierarchies. * Implement the <code>Abstraction</code> in terms of (by delegating to) an <code>Implementor</code> object. This enables to configure an <code>Abstraction</code> with an <code>Implementor</code> object at run-time. <br> See also the [[Unified Modeling Language]] class and sequence diagram below. ==Structure== === UML class and sequence diagram === [[File:w3sDesign Bridge Design Pattern UML.jpg|frame|none|A sample UML class and sequence diagram for the Bridge design pattern.<ref>{{cite web|title=The Bridge design pattern - Structure and Collaboration|url=http://w3sdesign.com/?gr=s02&ugr=struct|website=w3sDesign.com|access-date=2017-08-12}}</ref>]] In the above Unified Modeling Language [[class diagram]], an abstraction (<code>Abstraction</code>) is not implemented as usual in a single inheritance hierarchy. Instead, there is one hierarchy for an abstraction (<code>Abstraction</code>) and a separate hierarchy for its implementation (<code>Implementor</code>), which makes the two independent from each other. The <code>Abstraction</code> interface (<code>operation()</code>) is implemented in terms of (by delegating to) the <code>Implementor</code> interface (<code>imp.operationImp()</code>). <br> The [[Unified Modeling Language|UML]] [[sequence diagram]] shows the run-time interactions: The <code>Abstraction1</code> object delegates implementation to the <code>Implementor1</code> object (by calling <code>operationImp()</code> on <code>Implementor1</code>), which performs the operation and returns to <code>Abstraction1</code>. === Class diagram === [[Image:Bridge UML class diagram.svg|500px]] ; Abstraction (abstract class) : defines the abstract interface : maintains the Implementor reference. ; RefinedAbstraction (normal class) : extends the interface defined by Abstraction ; Implementor (interface) : defines the interface for implementation classes ; ConcreteImplementor (normal class) : implements the Implementor interface [[Image:Bridge pattern in LePUS3.1.gif|thumb|none|400px|Bridge in [[Lepus3|LePUS3]] ([https://web.archive.org/web/20180314162121/http://www.lepus.org.uk/ref/legend/legend.xml legend]) ]] == Example == <!-- Wikipedia is not a list of examples. Do not add examples from your favorite programming language here; this page exists to explain the design pattern, not to show how it interacts with subtleties of every language under the sun. Feel free to add examples here: http://en.wikibooks.org/wiki/Computer_Science/Design_Patterns/Bridge_pattern --> === C# === Bridge pattern compose objects in tree structure. It decouples abstraction from implementation. Here abstraction represents the client from which the objects will be called. An example implemented in C# is given below <syntaxhighlight lang="csharp"> // Helps in providing truly decoupled architecture public interface IBridge { void Function1(); void Function2(); } public class Bridge1 : IBridge { public void Function1() { Console.WriteLine("Bridge1.Function1"); } public void Function2() { Console.WriteLine("Bridge1.Function2"); } } public class Bridge2 : IBridge { public void Function1() { Console.WriteLine("Bridge2.Function1"); } public void Function2() { Console.WriteLine("Bridge2.Function2"); } } public interface IAbstractBridge { void CallMethod1(); void CallMethod2(); } public class AbstractBridge : IAbstractBridge { public IBridge bridge; public AbstractBridge(IBridge bridge) { this.bridge = bridge; } public void CallMethod1() { this.bridge.Function1(); } public void CallMethod2() { this.bridge.Function2(); } } </syntaxhighlight> The Bridge classes are the Implementation that uses the same interface-oriented architecture to create objects. On the other hand, the abstraction takes an instance of the implementation class and runs its method. Thus, they are completely decoupled from one another. === Crystal === <syntaxhighlight lang="crystal"> abstract class DrawingAPI abstract def draw_circle(x : Float64, y : Float64, radius : Float64) end class DrawingAPI1 < DrawingAPI def draw_circle(x : Float, y : Float, radius : Float) "API1.circle at #{x}:#{y} - radius: #{radius}" end end class DrawingAPI2 < DrawingAPI def draw_circle(x : Float64, y : Float64, radius : Float64) "API2.circle at #{x}:#{y} - radius: #{radius}" end end abstract class Shape protected getter drawing_api : DrawingAPI def initialize(@drawing_api) end abstract def draw abstract def resize_by_percentage(percent : Float64) end class CircleShape < Shape getter x : Float64 getter y : Float64 getter radius : Float64 def initialize(@x, @y, @radius, drawing_api : DrawingAPI) super(drawing_api) end def draw @drawing_api.draw_circle(@x, @y, @radius) end def resize_by_percentage(percent : Float64) @radius *= (1 + percent/100) end end class BridgePattern def self.test shapes = [] of Shape shapes << CircleShape.new(1.0, 2.0, 3.0, DrawingAPI1.new) shapes << CircleShape.new(5.0, 7.0, 11.0, DrawingAPI2.new) shapes.each do |shape| shape.resize_by_percentage(2.5) puts shape.draw end end end BridgePattern.test </syntaxhighlight> Output <pre> API1.circle at 1.0:2.0 - radius: 3.075 API2.circle at 5.0:7.0 - radius: 11.275 </pre> === C++ === <syntaxhighlight lang="cpp"> import std; class DrawingAPI { public: virtual ~DrawingAPI() = default; virtual std::string DrawCircle(float x, float y, float radius) const = 0; }; class DrawingAPI01 : public DrawingAPI { public: std::string DrawCircle(float x, float y, float radius) const override { return std::format("API01.circle at {}:{} - radius: {}", std::to_string(x), std::to_string(y), std::to_string(radius)); } }; class DrawingAPI02 : public DrawingAPI { public: std::string DrawCircle(float x, float y, float radius) const override { return std::format("API02.circle at {}:{} - radius: {}", std::to_string(x), std::to_string(y), std::to_string(radius)); } }; class Shape { public: Shape(const DrawingAPI& drawing_api): drawing_api_(drawing_api) {} virtual ~Shape() = default; virtual std::string Draw() const = 0; virtual float ResizeByPercentage(const float percent) = 0; protected: const DrawingAPI& drawing_api_; }; class CircleShape: public Shape { public: CircleShape(float x, float y, float radius, const DrawingAPI& drawing_api): Shape(drawing_api), x_(x), y_(y), radius_(radius) {} std::string Draw() const override { return drawing_api_.DrawCircle(x_, y_, radius_); } float ResizeByPercentage(const float percent) override { return radius_ *= (1.0f + percent/100.0f); } private: float x_, y_, radius_; }; int main(int argc, char** argv) { const DrawingAPI01 api1{}; const DrawingAPI02 api2{}; std::vector<CircleShape> shapes { CircleShape{1.0f, 2.0f, 3.0f, api1}, CircleShape{5.0f, 7.0f, 11.0f, api2} }; for (CircleShape& shape: shapes) { shape.ResizeByPercentage(2.5); std::println("{}", shape.Draw()); } return 0; } </syntaxhighlight> Output: <pre> API01.circle at 1.000000:2.000000 - radius: 3.075000 API02.circle at 5.000000:7.000000 - radius: 11.275000 </pre> === Java === The following [[Java (programming language)|Java]] program defines a bank account that separates the account operations from the logging of these operations. <syntaxhighlight lang="java"> // Logger has two implementations: info and warning @FunctionalInterface interface Logger { void log(String message); static Logger info() { return message -> System.out.println("info: " + message); } static Logger warning() { return message -> System.out.println("warning: " + message); } } abstract class AbstractAccount { private Logger logger = Logger.info(); public void setLogger(Logger logger) { this.logger = logger; } // the logging part is delegated to the Logger implementation protected void operate(String message, boolean result) { logger.log(message + " result " + result); } } class SimpleAccount extends AbstractAccount { private int balance; public SimpleAccount(int balance) { this.balance = balance; } public boolean isBalanceLow() { return balance < 50; } public void withdraw(int amount) { boolean shouldPerform = balance >= amount; if (shouldPerform) { balance -= amount; } operate("withdraw " + amount, shouldPerform); } } public class BridgeDemo { public static void main(String[] args) { SimpleAccount account = new SimpleAccount(100); account.withdraw(75); if (account.isBalanceLow()) { // you can also change the Logger implementation at runtime account.setLogger(Logger.warning()); } account.withdraw(10); account.withdraw(100); } } </syntaxhighlight> It will output: <pre> info: withdraw 75 result true warning: withdraw 10 result true warning: withdraw 100 result false </pre> === PHP === <syntaxhighlight lang="php> interface DrawingAPI { function drawCircle($x, $y, $radius); } class DrawingAPI1 implements DrawingAPI { public function drawCircle($x, $y, $radius) { echo "API1.circle at $x:$y radius $radius.\n"; } } class DrawingAPI2 implements DrawingAPI { public function drawCircle($x, $y, $radius) { echo "API2.circle at $x:$y radius $radius.\n"; } } abstract class Shape { protected $drawingAPI; public abstract function draw(); public abstract function resizeByPercentage($pct); protected function __construct(DrawingAPI $drawingAPI) { $this->drawingAPI = $drawingAPI; } } class CircleShape extends Shape { private $x; private $y; private $radius; public function __construct($x, $y, $radius, DrawingAPI $drawingAPI) { parent::__construct($drawingAPI); $this->x = $x; $this->y = $y; $this->radius = $radius; } public function draw() { $this->drawingAPI->drawCircle($this->x, $this->y, $this->radius); } public function resizeByPercentage($pct) { $this->radius *= $pct; } } class Tester { public static function main() { $shapes = array( new CircleShape(1, 3, 7, new DrawingAPI1()), new CircleShape(5, 7, 11, new DrawingAPI2()), ); foreach ($shapes as $shape) { $shape->resizeByPercentage(2.5); $shape->draw(); } } } Tester::main(); </syntaxhighlight> Output: API1.circle at 1:3 radius 17.5 API2.circle at 5:7 radius 27.5 === Scala === <syntaxhighlight lang="scala"> trait DrawingAPI { def drawCircle(x: Double, y: Double, radius: Double) } class DrawingAPI1 extends DrawingAPI { def drawCircle(x: Double, y: Double, radius: Double) = println(s"API #1 $x $y $radius") } class DrawingAPI2 extends DrawingAPI { def drawCircle(x: Double, y: Double, radius: Double) = println(s"API #2 $x $y $radius") } abstract class Shape(drawingAPI: DrawingAPI) { def draw() def resizePercentage(pct: Double) } class CircleShape(x: Double, y: Double, var radius: Double, drawingAPI: DrawingAPI) extends Shape(drawingAPI: DrawingAPI) { def draw() = drawingAPI.drawCircle(x, y, radius) def resizePercentage(pct: Double) { radius *= pct } } object BridgePattern { def main(args: Array[String]) { Seq ( new CircleShape(1, 3, 5, new DrawingAPI1), new CircleShape(4, 5, 6, new DrawingAPI2) ) foreach { x => x.resizePercentage(3) x.draw() } } } </syntaxhighlight> ===Python=== <syntaxhighlight lang="python"> """ Bridge pattern example. """ from abc import ABCMeta, abstractmethod NOT_IMPLEMENTED = "You should implement this." class DrawingAPI: __metaclass__ = ABCMeta @abstractmethod def draw_circle(self, x, y, radius): raise NotImplementedError(NOT_IMPLEMENTED) class DrawingAPI1(DrawingAPI): def draw_circle(self, x, y, radius): return f"API1.circle at {x}:{y} - radius: {radius}" class DrawingAPI2(DrawingAPI): def draw_circle(self, x, y, radius): return f"API2.circle at {x}:{y} - radius: {radius}" class DrawingAPI3(DrawingAPI): def draw_circle(self, x, y, radius): return f"API3.circle at {x}:{y} - radius: {radius}" class Shape: __metaclass__ = ABCMeta drawing_api = None def __init__(self, drawing_api): self.drawing_api = drawing_api @abstractmethod def draw(self): raise NotImplementedError(NOT_IMPLEMENTED) @abstractmethod def resize_by_percentage(self, percent): raise NotImplementedError(NOT_IMPLEMENTED) class CircleShape(Shape): def __init__(self, x, y, radius, drawing_api): self.x = x self.y = y self.radius = radius super(CircleShape, self).__init__(drawing_api) def draw(self): return self.drawing_api.draw_circle(self.x, self.y, self.radius) def resize_by_percentage(self, percent): self.radius *= 1 + percent / 100 class BridgePattern: @staticmethod def test(): shapes = [ CircleShape(1.0, 2.0, 3.0, DrawingAPI1()), CircleShape(5.0, 7.0, 11.0, DrawingAPI2()), CircleShape(5.0, 4.0, 12.0, DrawingAPI3()), ] for shape in shapes: shape.resize_by_percentage(2.5) print(shape.draw()) BridgePattern.test() </syntaxhighlight> ==See also== * [[Adapter pattern]] * [[Strategy pattern]] * [[Template method pattern]] ==References== {{reflist |refs= {{refn |name=GoFp151 |1= {{cite book |last1=Gamma |first1=Erich |author-link1=Erich Gamma |last2=Helm |first2=Richard |last3=Johnson |first3=Ralph |author-link3=Ralph Johnson (computer scientist) |last4=Vlissides |first4=John |author-link4=John Vlissides |title=Design Patterns: Elements of Reusable Object-Oriented Software |publisher=Addison-Wesley |year=1994 |isbn=0-201-63361-2 |url=https://archive.org/details/designpatternsel00gamm/ |url-access=registration |page=[https://archive.org/details/designpatternsel00gamm/page/151 151] }} }} }} ==External links== {{wikibooks|Computer Science/Design Patterns|Bridge pattern|Bridge pattern implementations in various languages}} * [https://web.archive.org/web/20090426061003/http://www.lepus.org.uk/ref/companion/Bridge.xml Bridge in UML and in LePUS3] (a formal modelling language) * {{cite book |url=http://www.informit.com/articles/article.aspx?p=30297 |title=C# Design Patterns: The Bridge Pattern |work=Sample Chapter|date=2002-12-20 }} From: {{cite book |url=http://www.informit.com/store/product.aspx?isbn=0-201-84453-2 |title=C# Design Patterns: A Tutorial |author=James W. Cooper |publisher=[[Addison-Wesley]]|isbn=0-201-84453-2|year=2003 }} {{Design Patterns Patterns}} {{DEFAULTSORT:Bridge Pattern}} [[Category:Software design patterns]] [[Category:Articles with example C Sharp code]] [[Category:Articles with example C++ code]] [[Category:Articles with example Java code]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Cite book
(
edit
)
Template:Cite web
(
edit
)
Template:Design Patterns Patterns
(
edit
)
Template:R
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)
Template:Sister project
(
edit
)
Template:Wikibooks
(
edit
)