DecoratorPatternflyweight Pattern
Matt Klein
Decorator Pattern
IntentAttach Additional responsibilities to an object by dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.AKAWrapper
Decorator: Motivation
Desire to add responsibilities to individual objectsTwo ApproachesInheritanceChoices are made staticallyInflexibleDecoratorDynamicUnlimited in number of added responsibilities
Decorator:Applicability
Use the Decorator Pattern…To add responsibilities to individual objects dynamically and transparentlyFor responsibilities that can be withdrawnWhen extension by subclassing is impractical
Decorator: Participants
ComponentDefines the interface for objects that can have responsibilities added to them dynamicallyConcreteComponentDefines an object to which additional responsibilities can be attached
Decorator: Participants
DecoratorMaintains a reference to a Component object and defines an interface that conforms to Component’sinterfaceConcreteDecoratorAdds responsibilities to the component
Decorator: Structure
Decorator: Consequences
GoodMore Flexibility than static inheritanceMuch easier to use than multiple inheritanceCan be used to mix and match featuresCan add the same property twiceAvoids feature laden classes high up in hierarchyAllows to easily add new features incrementally
Decorator: Consequences
BadA decorator and its component aren’t identicalFrom an object identity point of view, a decorated component is not identical to the component itselfDon’t rely on object identity when using decoratorsLots of little objectsOften end up with systems composed of lots of little objectsCan be hard to learn and debug
Decorator:Implementation
Interface conformanceDecorator object’s interface must conform to the interface of the component it decoratesOmitting the abstract Decorator classIf you’re adding just one responsibility, there’s no need to have the abstract Decorator class
Decorator:Implementation
Keeping Component classes lightweightComponent should stick to defining an interfaceChanging the skin of an object vs. changing the gutsStrategyvs. Decorator
Decorator: Related Patterns
AdapterProvides new interfacevs. changingresponsibilitiesCompositeCan be viewed as a degenerate composite with only one componentStrategySkin vs. Guts
Flyweight Pattern
IntentUse sharing to support large numbers of fine-grained objects efficiently
Flyweight:Motivation
Can be used when an application could benefit from using objects throughout their design, but a naïve implementation would be prohibitively expensiveObjects for each character in a document editorCost is too great!Can use flyweight to share characters
Intrinsic vs. Extrinsic
Intrinsicstate is stored in the flyweightInformation that’s independent of the flyweight’s contextSharedExtrinsicState depends on and varies with the flyweight’s contextCannot be shared
Flyweight:Applicability
Use the Flyweight pattern whenALLof the following are trueAn application uses a large number of objectsStorage costs are high because of the sheer quantity of objectsMost object state can be made extrinsicMany Groups of objects may be replaced by relatively few shared objects once extrinsic state is removedThe application doesn’t depend on object identity
Flyweight:Participants
FlyweightDeclares an interface through which flyweights can receive and act on extrinsic stateConcreteFlyweightImplements the Flyweight interface and adds storage for intrinsic state, if anyMust be shareable
Flyweight:Participants
FlyweightFactoryCreates and manages flyweight objectsEnsures that flyweights are shared properlyClientMaintains reference to flyweightsComputes or stores the extrinsic state of flyweights
Flyweight:Structure
Flyweight:Consequences
May introduce run-time costs associated with transferring, finding, and/or computing extrinsic stateCosts are offset by space savings
Flyweight:Consequences
Storage savings are a function of the following factors:The reduction inthe total number of instances that comes from sharingThe amount of intrinsic state per objectWhether extrinsic state is computed or stored
Flyweight: Consequences
Ideal situationHigh number of shared flyweightsObjects use substantial quantities of both intrinsic and extrinsic stateExtrinsic state is computed
Decorator:Implementation
Removing extrinsic stateSuccess of pattern depends on ability to remove extrinsic state from shared objectsNo help if there are many different kinds of extrinsic stateIdeally, state is computed separately
Flyweight:Implementation
Managing shared objectsObjects are shared so clients should not instantiateFlyweightFactory is used to create and share objectsGarbagecollection may not be necessary
Flyweight: Related Patterns
CompositeOften combined with flyweightProvides a logically hierarchical structure in terms of a directed-acyclic graph with shared leaf nodesState and StrategyBest implemented as flyweights
0
Embed
Upload