Loading…

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

on

  • 438 views

 

Statistics

Views

Total Views
438
Views on SlideShare
438
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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