Design Patterns & Refactoring Flyweight Oliver Haase

(1)

Design Patterns & Refactoring

Flyweight

Oliver Haase

HTWG Konstanz

(2)

Description

Classification: Object-based structural pattern

Purpose: Use small-grained objects together, to avoid instantiation of a large number of objects.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 2 / 12

(3)

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 objects.

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

→ huge overhead if modelled as 840 000 regular objects!

(4)

Idea

Divide object state into intrinsicandextrinsicstate, 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

(5)

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 objects.

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.

(6)

Structure

(7)

Participants

Flyweight: declares operations that get fed with the extrensic state ConcreteFlyweight:

implements theFlyweightinterface

keeps the intrinsic state of the (shared) object

UnsharedConcreteFlyweight: Possibly, some implementations of Flyweight are not shared — typically more coarse-grained objects 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

(8)

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.

(9)

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.

(10)

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 object, but stores these attributes per bigger chunks of text.

(11)

Related Patterns

Flyweight often combined withcomposite pattern, to build hierarchy of objects with shared (flyweight) leaves.

→State and →Strategy objects are preferably implemented as flyweight objects.

(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