1 / 25

Decorator Pattern flyweight Pattern

Matt Klein. Decorator Pattern flyweight Pattern. Decorator Pattern. Intent Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. AKA Wrapper. Decorator: Motivation.

dhillis
Download Presentation

Decorator Pattern flyweight Pattern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Matt Klein Decorator Patternflyweight Pattern

  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

More Related