Stoop 439-decorator

620 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
620
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Stoop 439-decorator

  1. 1. S.Ducasse 1 QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture. Stéphane Ducasse Stephane.Ducasse@univ-savoie.fr http://www.listic.univ-savoie.fr/~ducasse/ Decorator
  2. 2. S.Ducasse 2 License: CC-Attribution-ShareAlike 2.0 http://creativecommons.org/licenses/by-sa/2.0/
  3. 3. S.Ducasse 3 Decorator • Attach additional responsib • ilities to an object dynamically. • Decorators provide a • flexible alternative to • subclassing for extending • functionality. • Aka:Wrapper
  4. 4. S.Ducasse 4 Decorator Intent • Attach additional responsib ilities to an object dynamically. • Decorators provide a flexible alternative to • subclassing for extending functionality. • Aka:Wrapper
  5. 5. S.Ducasse 5 Motivation • Adding behavior to individual object not entire class • scrollbar • border
  6. 6. S.Ducasse 6 Inheritance? • Does not work well • Too much combination border, color, scrollbars, bounds, translation... • To static: Clients cannot control when to put a border or not...
  7. 7. S.Ducasse 7 Decorator • Enclose the component into another one that adds border...in another one that adds scrollbar... • The decorator conforms to the interface of the component it decorates so that its presence is transparent to the component's clients. • The decorator forwards requests to the component and may perform additional actions (such as drawing a border) before or after forwarding
  8. 8. S.Ducasse 8 Decorator Solution
  9. 9. S.Ducasse 9 Applicability • When responsibilities can be withdrawn • When responsibilities can be added transparently • When subclassing is not possible (combination explosion)
  10. 10. S.Ducasse 10 Possible Decorator Structure
  11. 11. S.Ducasse 11 Participants • Component (VisualComponent) • defines the interface for objects that can have responsibilities added to them dynamically. • ConcreteComponent (TextView) • defines an object to which additional responsibilities can be attached. • Decorator • maintains a reference to a Component object and defines an interface that conforms to Component's interface. • ConcreteDecorator (BorderDecorator, ScrollDecorator) • adds responsibilities to the component.
  12. 12. S.Ducasse 12 Collaborations • Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.
  13. 13. S.Ducasse 13 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.
  14. 14. S.Ducasse 14 Consequences • More flexibility than static inheritance. Dynamic addition of properties • Avoids feature-laden classes high up in the hierarchy. • Lots of little objects.
  15. 15. S.Ducasse 15 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
  16. 16. S.Ducasse 16 Wrapping or not? Conforming or not • With decorator • With strategies
  17. 17. S.Ducasse 17 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.
  18. 18. S.Ducasse 18 Known Uses • VisualWorks Wrapper hierarchy • Stream Decorators inVisualWorks: • BOSSTransporter is a stream decorator • FormattedStream is a stream decorator

×