Bridge Pattern
Bridge Pattern
Bridge Pattern
THE BRIDGE PATTERN
2
THE BRIDGE PATTERN
Say you have a geometric Shape class with a pair of subclasses: Circle and
3
THE BRIDGE PATTERN
Adding new shape types and colors to the hierarchy will grow it exponentially.
This problem occurs because we’re trying to extend the shape classes in two independent dimensions:
4
by form and by color. That’s a very common issue with class inheritance. .
THE BRIDGE PATTERN
The Bridge pattern attempts to solve this problem by switching from inheritance
5
THE BRIDGE PATTERN
:: Building the Bridge Pattern - I
7
Now the shape can delegate any color-related work to the linked
color object.
That reference will act as a bridge between the Shape and Color
classes. From now on, adding new colors won’t require changing
the shape hierarchy, and vice versa.
THE BRIDGE PATTERN
:: Building the Bridge Pattern - I
You can develop the remote control classes independently from the
10
device classes. All that’s needed is to create a new remote subclass.
For example, a basic remote control might only have two buttons,
but you could extend it with additional features, such as an extra
battery or a touchscreen.
The client code links the desired type of remote control with a
specific device object via the remote’s constructor.
THE BRIDGE PATTERN
:: Building the Bridge Pattern - I
11
THE BRIDGE PATTERN
:: Definition & Applicability
12
classes’ interfaces look the same as that of a particular class.
The Bridge pattern is designed to separate a class’ interface from its
implementation, so that you can vary or replace the implementation
without changing the client code.
Example:
Suppose that we have a program that displays a list of products in a
window. The simplest interface for that display is a simple JList box. But,
once a significant number of products have been sold, we may want to
display the products in a table along with their sales figures.
THE BRIDGE PATTERN
:: Building the Bridge Pattern - II
13
{…}
When we design a bridge class, we have to decide how the bridge will determine
which of the several classes it will instantiate. This could be decided based on the
values or quantity of data to be displayed, or based on some simple constants.
Here we define the two constants inside the ListBridge class:
14
Vector sort = sortVector(v); //sort the vector
if (table_type == LIST)
getViewport().add(makeList(sort)); //make table
if (table_type == TABLE)
getViewport().add(makeTable(sort)); //make list
}
THE BRIDGE PATTERN
:: Building the Bridge Pattern - IV
15
private JList makeList(Vector v) {
return new JList(new ListModel(v));
}
//---------------------------------
private JTable makeTable(Vector v) {
return new JTable(new TableModel(v));
}
16
}
private JTable makeTable(Vector v) {
return new JTable(new TableModel(v));
}
public ListBridge(Vector v, int table_type) { //constructor
Vector sort = sortVector(v); //sort the vector
if (table_type == LIST)
getViewport().add(makeList(sort)); //make table
if (table_type == TABLE)
getViewport().add(makeTable(sort)); //make list
}
}
THE BRIDGE PATTERN
:: Consequences of the Bridge Pattern
17
This can prevent you from recompiling a complicated set of user
interface modules, and only require that you recompile the bridge
itself and the actual end display class.
You can extend the implementation class and the bridge class
separately, and usually without much interaction with each other.