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