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