Design Patterns & Refactoring Bridge Oliver Haase HTWG - - PowerPoint PPT Presentation

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

CommImpl sendImpl() receiveImpl() Communication send(op, params): void receive(): Result RemoteOpComm invoke(op, params): Result impl.sendImpl(op,params); TcpCommunication sendImpl(op, params): void receiveImpl(): Result UdpCommunication sendImpl(op, params): void receiveImpl(): Result impl return impl.receiveImpl(); send(op, params); return receive(); Bridge Client 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

Bridge Implementor

• perationImpl()

Abstraction

• peration()

Specialization impl.operationImpl(); ConcreteImplementorA

• perationImpl()

ConcreteImplementorB

• perationImpl()

impl Client 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

• f 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