Design Patterns & Refactoring Bridge
Oliver Haase
HTWG Konstanz
‘A computer once beat me at chess, but it was no match to me at kick-boxing’ — Emo Philips
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 11 Description I
Classification: object based structural pattern Purpose: decouple abstraction (interfaces) and implementation, such that both can evolve independently
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 2 / 11 Motivation
Scenario: Provide more comfortable RemoteOpComm interface without modification of existing type hierarchy.
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 11 Motivation
Problem: Implementation classes TCPCommunication and UDPCommunication must be duplicated.
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 4 / 11 Motivation
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 5 / 11 Structure using Bridge Pattern
Client
Bridge Communication impl CommImpl send(op, params): void sendImpl() receive(): Result receiveImpl()
impl.sendImpl(op,params);
return impl.receiveImpl();
RemoteOpComm TcpCommunication UdpCommunication invoke(op, params): Result sendImpl(op, params): void sendImpl(op, params): void receiveImpl(): Result receiveImpl(): Result
send(op, params); return receive();
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 11 Implications
Please note that the abstractions (left hand side) use only the functionality provided by class CommImpl. Additional functionality in the subclasses cannot be taken advantage of; additional functionality in sub-interfaces must be achieved only through usage of the general functionality as contained in the root interface.
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 7 / 11 General Structure
Client
Bridge Abstraction impl Implementor operation() operationImpl()
impl.operationImpl();
ConcreteImplementorA ConcreteImplementorB Specialization operationImpl() operationImpl()
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 8 / 11 Description II
Members: Abstraction (Communication): defines interface of the abstraction maintains reference to Implementor instance Specialization (RemoteOpComm): extends Abstraction interface through usage of its operations Implementor (CommImpl): defines interface for implementation classes (can differ from Abstraction interface) ConcreteImplementor (TcpCommunication): provides implementation of Implementor interface
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 9 / 11 Description III
Interactions: Abstraction delegates requests to Implementor object Consequences: loose coupling of abstraction and implementation Implementor object can be replaced at run-time
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 10 / 11 Implementation
Who decides when and how, what particular Implementor object to use?
1 Specialization object, based on the params passed in at construction time. Example: Collection object that gets initialized with small initial size uses LinearList implementation. Large Collection object uses BTree implementation. (Note: Implementation can be dynamically replaced as the collection grows.) 2 Others decide → creational patterns! Specialization object gets fed with factory or prototype Dependency injection → Specialization object gets passed in Implementor object by Client.
Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 11 / 11