Matt klein
1 / 25

Decorator Pattern flyweight Pattern - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Decorator Pattern flyweight Pattern' - aron

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Matt klein

Matt Klein

Decorator Patternflyweight Pattern

Decorator 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
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

Decorator applicability
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

Decorator participants
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

Decorator participants1
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

Decorator consequences
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

Decorator consequences1
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

Decorator implementation
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

Decorator implementation1
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

Decorator related patterns
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

Flyweight pattern
Flyweight Pattern

  • Intent

    • Use sharing to support large numbers of fine-grained objects efficiently

Flyweight motivation
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

Intrinsic vs extrinsic
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

Flyweight applicability
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

Flyweight participants
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

Flyweight participants1
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

Flyweight structure
Flyweight: Structure

Flyweight consequences
Flyweight: Consequences

  • May introduce run-time costs associated with transferring, finding, and/or computing extrinsic state

  • Costs are offset by space savings

Flyweight consequences1
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

Flyweight consequences2
Flyweight: Consequences

  • Ideal situation

    • High number of shared flyweights

    • Objects use substantial quantities of both intrinsic and extrinsic state

    • Extrinsic state is computed

Decorator implementation2
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

Flyweight implementation
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

Flyweight related patterns
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