Design Pattern - Structural Patterns - Bridge Pattern

2007

Section 2, Chapter 4

Bridge Pattern

Concept

In the Bridge pattern we allow the instance variable to be not a concrete type but an abstract type, thus giving us a variance on which class we wish to adapt, or bridge.

Use

In case of inexact matches. Inexact matches occur when two class types are similar but not enough so for the compiler to recognize.

We have a class that has a single method and inherits a base.

We have an instance where our implementor is another class type that we do not want to inherit.

Design

• We desire a class's implementation, but we do not wish to inherit it;
  
• We inherit the bridge from the expected base type;
  
• We override the methods, properties, and events;
  
• We encapsulate the methods, properties, and events of the desired implementation class in those overrides;
  
• The instance of the internal abstract implementation is interchangeable because of its abstract status.
  

• Abstraction: the base for the bridge that holds the abstracted instance variable for the class to be adapted.
  
• Refined Abstraction: the concrete implementation of the abstracted bridge, where we define the methods, properties, and events for which we wish to provide a bridge.
  
• Abstract Implementor: the abstraction interface for the class for which we wish to bridge into the new type.
  
• Concrete Implementor: the concrete interface for the class for which we wish to bridge into the new type.
  

Illustration

Suppose we have the code in place as below:

class HttpRequest{public override void ProcessRequest(string request){.......}}class ISAPIRequest{public override void ProcessRequest(string request){.......}}class RequestHandler : Request{public override void Process(string request){//some implementation code}}

RequestHandler class has a method similar to the implementation classes (HttpRequest & ISAPIRequest) but named differently, the method's internal functionality is similar.

What we wish to do is to make the RequestHandler class use our implementor handler types, without inheritance from these types.

abstract class RequestImplementor{public abstract void ProcessRequest(string request);}

class HttpRequest : RequestImplementor{public override void ProcessRequest(string request){......}}class ISAPIRequest : RequestImplementor{public override void ProcessRequest(string request){......}}

abstract class Request{private RequestImplementor _implementor;// a private instance variable for the abstract implementorpublic void SetImplementor(RequestImplementor implementor)// a way to set the actual concrete implementation of our abstract implementor to the instance variable{_implementor = implementor;}protected RequestImplementor Implementor{get{return _implementor;}}public abstract void Process(string request);// will be used to allow the inherited instances of Request to have a common method}

class RequestHandler : Request{public override void Process(string request){Implementor.ProcessRequest(request);}}

Request request = new RequestHandler();request.SetImplementor(new HttpRequest());request.Process("This is a HTTP request stream..");request.SetImplementor(new ISAPIRequest());request.Process("This is a ISAPI request stream..");