Pattern flyweight Pattern Matt Klein Decorator Pattern Intent Attach Additional responsibilities to an object by dynamically Decorators provide a flexible alternative to subclassing for extending functionality ID: 257777
Download Presentation The PPT/PDF document "Decorator" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Decorator Patternflyweight Pattern
Matt KleinSlide2
Decorator Pattern
Intent
Attach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
AKA
WrapperSlide3
Decorator: Motivation
Desire to add responsibilities to individual objects
Two Approaches
Inheritance
Choices are made statically
Inflexible
Decorator
Dynamic
Unlimited in number of added responsibilitiesSlide4
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 impracticalSlide5
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 attachedSlide6
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 componentSlide7
Decorator: StructureSlide8
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 incrementallySlide9
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 debugSlide10
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 classSlide11
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. DecoratorSlide12
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. GutsSlide13
Flyweight Pattern
Intent
Use sharing to support large numbers of fine-grained objects efficientlySlide14
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 charactersSlide15
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 sharedSlide16
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 identitySlide17
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 shareableSlide18
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 flyweightsSlide19
Flyweight: StructureSlide20
Flyweight: Consequences
May introduce run-time costs associated with transferring, finding, and/or computing extrinsic state
Costs are offset by space savingsSlide21
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 storedSlide22
Flyweight: Consequences
Ideal situation
High number of shared flyweights
Objects use substantial quantities of both intrinsic and extrinsic state
Extrinsic state is computedSlide23
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 separatelySlide24
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 necessarySlide25
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