Object Bridge

pattern
IMPLEMENTATION OF THREAD SCHEDULING
Bridge Pattern overview

 The Bridge design pattern allows you to separate the abstraction

from the implementation. It is a structural design pattern.

 There are 2 parts in Bridge design pattern :

 Abstraction
 Implementation
Bridge Pattern Overview

 This is a design mechanism that encapsulates an implementation class inside of

an interface class.
 The bridge pattern allows the Abstraction and the Implementation to be
developed independently and the client code can access only the Abstraction
part without being concerned about the Implementation part.
 The abstraction is an interface or abstract class and the implementer is also an
interface or abstract class.
 The abstraction contains a reference to the implementer.
 Children of the abstraction are referred to as refined abstractions, and children
of the implementer are concrete implementers.
 Since we can change the reference to the implementer in the abstraction, we
are able to change the abstraction’s implementer at run-time. Changes to the
implementer do not affect client code.
 It increases the loose coupling between class abstraction and it’s
implementation.
UML Diagram of Bridge Design pattern
Elements of Bridge Design Pattern

 Abstraction – core of the bridge design pattern and defines the

crux. Contains a reference to the implementer.
 Refined Abstraction – Extends the abstraction takes the finer detail
one level below. Hides the finer elements from implementers.
 Implementer – It defines the interface for implementation classes.
This interface does not need to correspond directly to abstraction
interface and can be very different. Abstraction imp provides an
implementation in terms of operations provided by Implementer
interface.
 Concrete Implementation – Implements the above implementer by
providing concrete implementation.
Example of Bridge design pattern
 Here we’re producing and assembling the two different vehicles using
Bridge design pattern.
 In the first diagram we will see the elements and their relationships when
we don’t use Object bridge pattern.
 In the Second diagram we will see the elements and their relationships
when we use the Object bridge pattern.
When we need bridge design pattern:-
 The Bridge pattern is an application of the old advice, “prefer
composition over inheritance”. It becomes handy when you must
subclass different times in ways that are orthogonal with one another.
Without Bridge Design Pattern
 Consider the below design pattern :

 But above solution has a problem. If you want to change Bus

class, then you may end up changing ProduceBus and
AssembleBus as well and if the change is workshop specific then
you may need to change Bike class as well.
With Bridge Design Pattern

 We can solve above problem by decoupling the Vehicle and

Workshop interfaces in below manner.

Advantages

 Bridge pattern decouple an abstraction from its implementation so

that the two can vary independently.
 It is used mainly for implementing platform independence feature.
 It adds one more method level redirection to achieve the objective.
 Publish abstraction interface in separate inheritance hierarchy, and
put implementation in its own inheritance hierarchy.
 Use bridge pattern to run-time binding of the implementation.
 Use bridge pattern to map orthogonal class hierarchies
 Bridge is designed up-front to let the abstraction and the
implementation vary independently.
Implementation of thread
scheduling – problem definition
 Let us consider the domain of thread scheduling


 There are two types of thread schedulers, and two types of

operating systems or "platforms".
Implementation of thread
scheduling – simple solution
 Given this approach to specialization, we have to define a class for
each permutation of these two dimensions.
 If we add a new platform (say ... Java's Virtual Machine), what
would our hierarchy look like?

Implementation of thread
scheduling – Solution: object Bridge
 The number of classes we would have to define would increase with
the number of scheduling schemes and the number of platforms.
 If we apply the Bridge design pattern we get two orthogonal
hierarchies – one for platform-independent abstractions, and the
other for platform-dependent implementations.

Discussion of solution

 Decompose the component's interface and implementation into

orthogonal class hierarchies.
 The interface class contains a pointer to the abstract implementation
class.
 This pointer is initialized with an instance of a concrete implementation
class, but all subsequent interaction from the interface class to the
implementation class is limited to the abstraction maintained in the
implementation base class.
 The client interacts with the interface class, and it in turn "delegates" all
requests to the implementation class.
 The interface object is the "handle" known and used by the client; while
the implementation object, or "body", is safely encapsulated to ensure
that it may continue to evolve, or be entirely replaced (or shared at
run-time.
Discussion – when to use object
bridge
Use the Bridge pattern when:
 you want run-time binding of the implementation,
 you have a proliferation of classes resulting from a coupled
interface and numerous implementations,
 you want to share an implementation among multiple objects,
 you need to map orthogonal class hierarchies.
Consequences include:
 decoupling the object's interface,
 improved extensibility (you can extend (i.e. subclass) the abstraction
and implementation hierarchies independently),
 hiding details from clients.
Conclusion

 Bridge is a synonym for the "handle/body" idiom.

 This is a design mechanism that encapsulates an implementation
class inside of an interface class.
 The former is the body, and the latter is the handle. The handle is
viewed by the user as the actual class, but the work is done in the
body.
 "The handle/body class idiom may be used to decompose a
complex abstraction into smaller, more manageable classes.
 The idiom may reflect the sharing of a single resource by multiple
classes that control access to it (e.g. reference counting)."
Check List:

 Decide if two orthogonal dimensions exist in the domain.

 These independent concepts could be: abstraction/platform, or
domain/infrastructure, or front-end/back-end, or
interface/implementation.
 Design the separation of concerns: what does the client want, and
what do the platforms provide.
 Design a platform-oriented interface that is minimal, necessary, and
sufficient. Its goal is to decouple the abstraction from the platform.
 Define a derived class of that interface for each platform.
 Create the abstraction base class that "has a" platform object and
delegates the platform-oriented functionality to it.
 Define specializations of the abstraction class if desired.
Rules of thumb
 Adapter makes things work after they're designed; Bridge makes them work
before they are.
 Bridge is designed up-front to let the abstraction and the implementation vary
independently. Adapter is retrofitted to make unrelated classes work together.
 State, Strategy, Bridge (and to some degree Adapter) have similar solution
structures. They all share elements of the "handle/body" idiom. They differ in
intent - that is, they solve different problems.
 The structure of State and Bridge are identical (except that Bridge admits
hierarchies of envelope classes, whereas State allows only one). The two
patterns use the same structure to solve different problems: State allows an
object's behavior to change along with its state, while Bridge's intent is to
decouple an abstraction from its implementation so that the two can vary
independently.
 If interface classes delegate the creation of their implementation classes
(instead of creating/coupling themselves directly), then the design usually uses
the Abstract Factory pattern to create the implementation objects.