design patterns refactoring
play

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


  1. 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

  2. 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

  3. Motivation Scenario: Provide more comfortable RemoteOpComm interface without modification of existing type hierarchy. Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 11

  4. Motivation Problem: Implementation classes TCPCommunication and UDPCommunication must be duplicated. Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 4 / 11

  5. Motivation Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 5 / 11

  6. Structure using Bridge Pattern Client Bridge Communication impl CommImpl send(op, params): void sendImpl() receive(): Result receiveImpl() impl.sendImpl(op,params); return impl.receiveImpl(); TcpCommunication UdpCommunication RemoteOpComm sendImpl(op, params): void sendImpl(op, params): void invoke(op, params): Result receiveImpl(): Result receiveImpl(): Result send(op, params); return receive(); Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 11

  7. 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

  8. 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

  9. 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

  10. 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

  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

Recommend


More recommend