Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Stoop 440-adaptor






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Stoop 440-adaptor Stoop 440-adaptor Presentation Transcript

    • Adapter
    • Adapter
      • Convert the interface of a class into another interface clients expect.
      • Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
      • Aka: Wrapper
    • Motivation
      • Sometimes a toolkit class designed for reuse isn't reusable only because its interface doesn't match the domain-specific interface an application requires.
    • Adapter Solution
    • Possible Adapter Structures
    • Participants
      • Target (Shape)
        • defines the domain-specific interface that Client uses.
      • Client (DrawingEditor)
        • collaborates with objects conforming to the Target interface.
      • Adaptee (TextView)
        • defines an existing interface that needs adapting.
      • Adapter (TextShape)
        • adapts the interface of Adaptee to the Target interface.
    • Collaborations
      • Clients call operations on an Adapter instance. In turn, the adapter calls Adaptee operations that carry out the request.
    • About Identity
      • A decorator and its component aren't identical.
      • A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself.
      • If the decorator is wrapping, then identity of the object may change.
      • Good at construction time, but else should “adapt” the references from the decorated to the decorator.
    • Consequences
      • More flexibility than static inheritance. Dynamic addition of properties
      • Avoids feature-laden classes high up in the hierarchy.
      • Lots of little objects.
    • Implementation
      • Interface conformance. A decorator object's interface must conform to the interface of the component it decorates. ConcreteDecorator classes must therefore inherit from a common class (at least in C++).
      • Omitting the abstract Decorator class. There's no need to define an abstract Decorator class when you only need to add one responsibility.
      • Keeping Component classes lightweight. Component should specify an interface, decorators are then easier to define
    • Wrapping or not? Conforming or not
      • With decorator
      • With strategies
    • Strategies?
      • Strategies are a better choice when the Component class is heavyweight, thereby making the Decorator pattern too costly to apply.
      • The Strategy-based approach might require modifying the component to accommodate new extensions.
      • - a strategy can have its own specialized interface,
      • - a decorator's interface must conform to the component's.
      • A strategy needs only define the interface for rendering a border, which means that the strategy can be lightweight even if the Component class is heavyweight.
    • Known Uses
      • VisualWorks Wrapper hierarchy
      • Stream Decorators in VisualWorks:
        • BOSSTransporter is a stream decorator
        • FormattedStream is a stream decorator