Design Patterns and Frameworks Flyweight Oliver Haase Oliver Haase - - PowerPoint PPT Presentation

Design Patterns and Frameworks – Flyweight

Oliver Haase

Oliver Haase Emfra — Flyweight 1/12

Description

◮ Classification: Object-based structural pattern ◮ Purpose: Use small-grained objects together, to avoid

instantiation of a large number of objects.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler.

Oliver Haase Emfra — Flyweight 2/12

Motivation

◮ Imagine a text processor that represents text documents

consisting of pages, rows, words, and characters.

◮ for homogeneity, it would be nice to treat the concepts of

pages, rows, words, and characters similarly, in particular as

• bjects.

◮ Problem: A book with 300 pages can easily contain 840 000

characters → huge overhead if modelled as 840 000 regular objects!

Oliver Haase Emfra — Flyweight 3/12

Idea

◮ Divide object state into intrinsic and extrinsic state, such that

there is only a small number of distinct objects with different intrinsic states.

◮ Share these flyweight objects. ◮ Feed them with extrinsic state for operation invocations.

Character Flyweight Objects intrinsic state: character code (e.g. Unicode) extrinsic state: font, text style (bold, italics, regular), position

Oliver Haase Emfra — Flyweight 4/12

Description

◮ Applicability: Use the flyweight pattern only if all of the

following apply

◮ An application uses a large number of objects. ◮ The memory consumption forbids instantiation of individual

• bjects.

◮ A big part of the object state can be moved into the context

(can be made extrinsic).

◮ Removal of the extrinsic state results in a small number of

distinct objects.

◮ Thr application does not depend on the object identity. Oliver Haase Emfra — Flyweight 5/12

Structure

Oliver Haase Emfra — Flyweight 6/12

Participants

◮ Flyweight: declares operations that get fed with the extrensic

state

◮ ConcreteFlyweight:

◮ implements the Flyweight interface ◮ keeps the intrinsic state of the (shared) object

◮ UnsharedConcreteFlyweight: Possibly, some implementations

• f Flyweight are not shared — typically more coarse-grained
• bjects on a higher layer of the application. The objects can

keep not only their intrinsic, but their complete state.

◮ FlyweightFactory: creates and maintains the flyweight objects. ◮ Client:

◮ has references to the flyweight objects ◮ keeps or computes the objects’ extrinsic state Oliver Haase Emfra — Flyweight 7/12

Interactions

◮ Intrinsic and extrinsic state must be clearly distinguishable.

Flyweight objects store intrinsic state, clients store or compute extrinsic state and supply it into flyweight’s operations.

◮ Clients don’t create flyweight objects directly. A flyweight

factory makes sure flyweight objects are correctly shared.

Oliver Haase Emfra — Flyweight 8/12

Consequences

◮ Reduced memory consumption comes at the cost of increased

runtime, because client has to compute or access stored extrinsic state information, and pass it into flyweight objects.

◮ Memory saving depends on

◮ degree of reduction of objects; ◮ size of intrinsic state; ◮ whether extrinsic state is stored or calculated. Oliver Haase Emfra — Flyweight 9/12

Extrinsic State

◮ Applicability depends on how easily extrinsic state information

can be identified and pulled out.

◮ Benefit (in terms of memory consumption) depends on

whether the amount of extrinsic state for all flyweight objects equals the original state information or not. Example → character flyweight objects: intrinsic state: Character code (e.g. Unicode) extrinsic state: font, text style, position Client doesn’t have to store font and text style per flyweight

• bject, but stores these attributes per bigger chunks of text.

Oliver Haase Emfra — Flyweight 10/12

Related Patterns

◮ Flyweight often combined with composite pattern, to build

hierarchy of objects with shared (flyweight) leaves.

◮ →State and →Strategy objects are preferably implemented

as flyweight objects.

Oliver Haase Emfra — Flyweight 11/12

Closing Remarks

◮ Normally, patterns are intended to keep design simply, to

reduce dependencies, to reduce number of classes, etc. → simplicity, clarity, maintainability, & friends

◮ sometimes — though not always — at the expense of reduced

efficiency

◮ In contrast, flyweight pattern motivated by efficiency

considerations → relevance can be expected to decrease as main memory continously gets cheaper

Oliver Haase Emfra — Flyweight 12/12