Bridge

There is another way to look at this problem. The need for a dedicated modem has added a new degree of freedom to the Modem type hierarchy. When the Modem type was conceived, it was simply an interface for a set of different hardware devices. Thus, we had HayesModem, USRModem, and ErniesModem deriving from the base Modem class. Now, however, it appears that there is another way to cut at the modem hierarchy. We could have DialModem and DedicatedModem deriving from Modem.

Merging these two independent hierarchies can be done as shown in Figure 33-10. Each of the leaves of the type hierarchy puts either a dialup or dedicated behavior onto the hardware it controls. A DedicatedHayesModem object controls a Hayes modem in a dedicated context.

Figure 33-10. Solving the modem problem by merging type hierarchies

This is not an ideal structure. Every time we add a new piece of hardware, we must create two new classes: one for the dedicated case and one for the dialup case. Every time we add a new connection type, we have to create three new classes, one for each of the different pieces of hardware. If these two degrees of freedom are at all volatile, we could soon wind up with a large number of derived classes.

We can solve this problem by applying the BRIDGE pattern. This pattern often helps when a type hierarchy has more than one degree of freedom. Rather than merge the hierarchies, we can separate them and tie them together with a bridge.

Figure 33-11 shows the structure. We split the modem hierarchy into two hierarchies. One represents the connection method, and the other represents the hardware.

Figure 33-11. BRIDGE solution to the modem problem

Modem users continue to use the Modem interface. ModemConnectionController implements the Modem interface. The derivatives of ModemConnectionController control the connection mechanism. DialModemController simply passes the dial and hangup method to dialImp and hangImp in the ModemConnectionController base class. Those methods then delegate to the ModemImplementation class, where they are deployed to the appropriate hardware controller. DedModemController implements dial and hangup to simulate the connection state. It passes send and receive to sendImp and receiveImp, which are then delegated to the ModemImplementation hierarchy as before.

Note that the four imp functions in the ModemConnectionController base class are protected; they are to be used strictly by derivatives of ModemConnectionController. No one else should be calling them.

This structure is complex but interesting. We are able to create it without affecting the modem users, yet it allows us to completely separate the connection policies from the hardware implementation. Each derivative of ModemConnectionController represents a new connection policy. That policy can use sendImp, receiveImp, dialImp, and hangImp to implement that policy. New imp functions could be created without affecting the users. ISP could be used to add new interfaces to the connection controller classes.

This could create a migration path that the modem clients could slowly follow toward an API that is higher level than dial and hangup.