The UML diagram in Figure 10.2 for the Bridge pattern shows the separation of the interface and the implementation. The Bridger class on the left is the Abstraction, and the listBridge class is the implementation of that abstraction. The visList interface describes the public interface to the list classes productList and productTable. The visList interface defines the interface of the Implementor, and the Concrete Implementors are the productList and productTable classes.

Figure 10.2. The UML diagram for the Bridge pattern used in the two displays of product information.

Note that these two concrete implementors are quite different in their specifics even though they both support the visList interface.

Now suppose that we need to make some changes in the way these lists display the data. For example, you might want to have the products displayed in alphabetical order. You might think you'd need to either modify or subclass both the list and table classes. This can quickly get to be a maintenance nightmare, especially if more than two such displays eventually are needed. Instead, we simply make the changes in the extended interface class, creating a new sortBridge class from the parent listBridge class.

public class sortBridge extends listBridge {

    public sortBridge(visList jlist) {
        super(jlist);
        }
//--------------
    public void addData(Vector v) {
        Vector sv = sortData(v);

        for(int i = 0; i < sv.size(); i++) {
            String s = (String)sv.elementAt (i);
            list.addLine (s);
        }
    }
//--------------
    private Vector sortData(Vector v) {
        String s[] = new String[v.size()];
        for(int i = 0; i < v.size(); i++)
            s[i] = (String)v.elementAt (i);
        for(int i = 0; i < v.size(); i++) {
            for(int j = i; j < v.size(); j++) {
                if(s[i].compareTo (s[j]) > 0) {
                    String tmp = s[i];
                    s[i] = s[j];
                    s[j] = tmp;
                }
            }
        }
    Vector v1 = new Vector();
    for (int i = 0; i < v.size(); i++) {
        v1.addElement(s[i]);
        System.out.println(i+" "+s[i]);
    }
        return v1;
    }
}

This code shows that you can vary the interface without changing the implementation. The converse is also true. For example, you could create another type of list display and replace one of the current list displays without any other program changes, as long as the new list also implements the visList interface.

In the example in Figure 10.3, we have created a tree list component that inplements the visList interface. The ordinary list is replaced without any change in the public interface to the classes.

Figure 10.3. Another display using a Bridge to a tree list.

The Java Beans programming model is an ideal example of a Bridge pattern implementation. A Java Bean is a reusable software component that can be manipulated visually in a Builder tool. All of the JFC components are written as Beans, which means that they support a query interface (using the Introspector class) that enables builder programs to enumerate their properties and display them for easy modification. Figure 10.4 shows a screen from Symantec Visual Café, showing a panel with a text field and a check box. The builder panel to the right shows how you can modify the properties of either of those components by using a simple visual interface.

Figure 10.4. A screen from Symantec Visual Café showing a Java Bean interface. The property lists are implemented using a Bridge pattern.

In other words, all Java Beans have the same interface used by the builder program, and you can substitute any Bean for any other and still manipulate its properties using the same convenient interface. The actual program you construct uses these classes in a conventional way, each having its own rather different methods. However, from the builder's point of view, they all appear to be the same.

Using the Bridge pattern has the following consequences: