Design Patterns & Refactoring Flyweight Oliver Haase HTWG - - PowerPoint PPT Presentation

Design Patterns & Refactoring

Flyweight Oliver Haase

HTWG Konstanz

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

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

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!

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

Idea

Divide object state into intrinsic and extrinsic state, such that there is

• nly 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 (HTWG Konstanz) Design Patterns & Refactoring 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 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

• bjects.

Thr application does not depend on the object identity.

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

Structure

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 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 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

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

Interactions

Intrinsic and extrinsic state must be clearly distinguishable. Flyweight

• bjects 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 (HTWG Konstanz) Design Patterns & Refactoring 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 (HTWG Konstanz) Design Patterns & Refactoring 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 object, but stores these attributes per bigger chunks of text.

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

Related Patterns

Flyweight often combined with composite pattern, to build hierarchy

• f objects with shared (flyweight) leaves.

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

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 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 (HTWG Konstanz) Design Patterns & Refactoring 12 / 12