Presentation is loading. Please wait.

Presentation is loading. Please wait.

Matt Klein. Decorator Pattern  Intent  Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to.

Similar presentations

Presentation on theme: "Matt Klein. Decorator Pattern  Intent  Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to."— Presentation transcript:

1 Matt Klein

2 Decorator Pattern  Intent  Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.  AKA  Wrapper

3 Decorator: Motivation  Desire to add responsibilities to individual objects  Two Approaches  Inheritance  Choices are made statically  Inflexible  Decorator  Dynamic  Unlimited in number of added responsibilities

4 Decorator: Applicability  Use the Decorator Pattern…  To add responsibilities to individual objects dynamically and transparently  For responsibilities that can be withdrawn  When extension by subclassing is impractical

5 Decorator: Participants  Component  Defines the interface for objects that can have responsibilities added to them dynamically  ConcreteComponent  Defines an object to which additional responsibilities can be attached

6 Decorator: Participants  Decorator  Maintains a reference to a Component object and defines an interface that conforms to Component’s interface  ConcreteDecorator  Adds responsibilities to the component

7 Decorator: Structure

8 Decorator: Consequences  Good  More Flexibility than static inheritance  Much easier to use than multiple inheritance  Can be used to mix and match features  Can add the same property twice  Avoids feature laden classes high up in hierarchy  Allows to easily add new features incrementally

9 Decorator: Consequences  Bad  A decorator and its component aren’t identical  From an object identity point of view, a decorated component is not identical to the component itself  Don’t rely on object identity when using decorators  Lots of little objects  Often end up with systems composed of lots of little objects  Can be hard to learn and debug

10 Decorator: Implementation  Interface conformance  Decorator object’s interface must conform to the interface of the component it decorates  Omitting the abstract Decorator class  If you’re adding just one responsibility, there’s no need to have the abstract Decorator class

11 Decorator: Implementation  Keeping Component classes lightweight  Component should stick to defining an interface  Changing the skin of an object vs. changing the guts  Strategy vs. Decorator

12 Decorator: Related Patterns  Adapter  Provides new interface vs. changing responsibilities  Composite  Can be viewed as a degenerate composite with only one component  Strategy  Skin vs. Guts

13 Flyweight Pattern  Intent  Use sharing to support large numbers of fine- grained objects efficiently

14 Flyweight: Motivation  Can be used when an application could benefit from using objects throughout their design, but a naïve implementation would be prohibitively expensive  Objects for each character in a document editor  Cost is too great!  Can use flyweight to share characters

15 Intrinsic vs. Extrinsic  Intrinsic  state is stored in the flyweight  Information that’s independent of the flyweight’s context  Shared  Extrinsic  State depends on and varies with the flyweight’s context  Cannot be shared

16 Flyweight: Applicability  Use the Flyweight pattern when ALL of the following are true  An application uses a large number of objects  Storage costs are high because of the sheer quantity of objects  Most object state can be made extrinsic  Many Groups of objects may be replaced by relatively few shared objects once extrinsic state is removed  The application doesn’t depend on object identity

17 Flyweight: Participants  Flyweight  Declares an interface through which flyweights can receive and act on extrinsic state  ConcreteFlyweight  Implements the Flyweight interface and adds storage for intrinsic state, if any  Must be shareable

18 Flyweight: Participants  FlyweightFactory  Creates and manages flyweight objects  Ensures that flyweights are shared properly  Client  Maintains reference to flyweights  Computes or stores the extrinsic state of flyweights

19 Flyweight: Structure

20 Flyweight: Consequences  May introduce run-time costs associated with transferring, finding, and/or computing extrinsic state  Costs are offset by space savings

21 Flyweight: Consequences  Storage savings are a function of the following factors:  The reduction in the total number of instances that comes from sharing  The amount of intrinsic state per object  Whether extrinsic state is computed or stored

22 Flyweight: Consequences  Ideal situation  High number of shared flyweights  Objects use substantial quantities of both intrinsic and extrinsic state  Extrinsic state is computed

23 Decorator: Implementation  Removing extrinsic state  Success of pattern depends on ability to remove extrinsic state from shared objects  No help if there are many different kinds of extrinsic state  Ideally, state is computed separately

24 Flyweight: Implementation  Managing shared objects  Objects are shared so clients should not instantiate  FlyweightFactory is used to create and share objects  Garbage collection may not be necessary

25 Flyweight: Related Patterns  Composite  Often combined with flyweight  Provides a logically hierarchical structure in terms of a directed-acyclic graph with shared leaf nodes  State and Strategy  Best implemented as flyweights

Download ppt "Matt Klein. Decorator Pattern  Intent  Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to."

Similar presentations

Ads by Google