Scribd Logo
Upload

Welcome to Scribd!

  • 37 views

    Session 17

    Uploaded by

    ganesh
    The bridge pattern decouples an abstraction from its implementation so they can vary independently. It uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The bridge pattern is useful when the class and what it does vary often, acting as two layers of abstraction. It is often confused with and implemented using the adapter pattern.

    Copyright:

    © All Rights Reserved
    Download as DOC, PDF, TXT or read online from Scribd

    Session 17

    Uploaded by

    ganesh
    37 views2 pages
    The bridge pattern decouples an abstraction from its implementation so they can vary independently. It uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The bridge pattern is useful when the class and what it does vary often, acting as two layers of abstraction. It is often confused with and implemented using the adapter pattern.

    Original Title

    SESSION 17

    Copyright

    © © All Rights Reserved

    Available Formats

    DOC, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The bridge pattern decouples an abstraction from its implementation so they can vary independently. It uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The bridge pattern is useful when the class and what it does vary often, acting as two layers of abstraction. It is often confused with and implemented using the adapter pattern.

    Copyright:

    © All Rights Reserved
    Download as DOC, PDF, TXT or read online from Scribd
    Download as doc, pdf, or txt
    37 views2 pages

    Session 17

    Uploaded by

    ganesh
    The bridge pattern decouples an abstraction from its implementation so they can vary independently. It uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The bridge pattern is useful when the class and what it does vary often, acting as two layers of abstraction. It is often confused with and implemented using the adapter pattern.

    Copyright:

    © All Rights Reserved
    Download as DOC, PDF, TXT or read online from Scribd
    Download as doc, pdf, or txt
    of 2

    STRUCTURAL BRIDGE:

    The bridge pattern is a design pattern used in software engineering which is meant to

    "decouple an abstraction from its implementation so that the two can vary independently".[1] The

    bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into

    different classes.

    When a class varies often, the features of object-oriented programming become very useful

    because changes to a program's code can be made easily with minimal prior knowledge about the

    program.

    The bridge pattern is useful when both the class and what it does vary often. The class itself

    can be thought of as the implementation and what the class can do as the abstraction. The bridge

    pattern can also be thought of as two layers of abstraction.

    When there is only one fixed implementation, this pattern is known as the Pimpl idiom in the C++

    world.

    The bridge pattern is often confused with the adapter pattern. In fact, the bridge pattern is

    often implemented using the class adapter pattern, e.g. in the Java code below.

    Variant: The implementation can be decoupled even more by deferring the presence of the

    implementation to the point where the abstraction is utilized.

    Abstraction (abstract class) defines the abstract interface maintains the Implementor reference.

    RefinedAbstraction (normal class) extends the interface defined by Abstraction

    Implementor (interface)defines the interface for implementation classes

    ConcreteImplementor (normal class)implements the Implementor interface

    ADAPTER and STRUCTURE:

    Intent

    Convert the interface of a class into another interface clients expect. Adapter lets classes work

    together that couldn't otherwise because of incompatible interfaces. [GoF, p139]

    Wrap an existing class with a new interface.

    Impedance match an old component to a new system

    Problem
    An "off the shelf" component offers compelling functionality that you would like to reuse,

    but its "view of the world" is not compatible with the philosophy and architecture of the system

    currently being developed.

    Structure category: wrapper

    Similar patterns: Facade Proxy

    Discussion

    Reuse has always been painful and elusive. One reason has been the tribulation of designing

    something new, while reusing something old. There is always something not quite right between the

    old and the new. It may be physical dimensions or misalignment. It may be timing or

    synchronization. It may be unfortunate assumptions or competing standards.

    It is very similar to the electrical engineering activity of "impedance matching" – adapting

    the input resistance, inductance, and capacitance of a load to match the output impedance of a

    source.

    STRUCTURE:

    Below, a legacy Rectangle component's display() method expects to receive "x, y, w, h"

    parameters. But the client wants to pass "upper left x and y" and "lower right x and y". This

    incongruity can be reconciled by adding an additional level of indirection – i.e. an Adapter object.

    BEHAVIORAL – STRATEGY:

    A generic value of the software community for years has been, "maximize cohesion and

    minimize coupling". The object-oriented design approach shown in Figure 21-1 is all about

    minimizing coupling. Since the client is coupled only to an abstraction (i.e. a useful fiction), and not

    a particular realization of that abstraction, the client could be said to be practicing "abstract

    coupling" . an object-oriented variant of the more generic exhortation "minimize coupling".

    You might also like