1. The Flyweight Pattern (Structural) ©SoftMoore ConsultingSlide 1

2. Motivation Some applications would benefit from using objects, but a naive implementation would create thousands of small objects, which would consume lots of memory and incur unacceptable run-time overhead. Example: Using an object-oriented approach to implementing a document editor, should we use objects to represent each character in the document? The Flyweight pattern describes how to share objects to allow their use at fine granularities without prohibitive costs. ©SoftMoore ConsultingSlide 2

3. Intrinsic versus Extrinsic State A flyweight is a shared object that can be used in multiple contexts simultaneously. Flyweights cannot make assumptions about the context in which they operate. The state of an object is the complete set of all attribute values of that object at a point in time. A flyweight object can have both intrinsic state and extrinsic state. Intrinsic State –independent of the flyweight’s context –stored in the flyweight Extrinsic State –depends on and varies with the object’s context –cannot be shared (cannot be stored in the flyweight) ©SoftMoore ConsultingSlide 3

4. Intrinsic versus Extrinsic State (continued) Example: A document editor can create a flyweight for each letter of the alphabet. The character code is intrinsic state and is stored as part of the flyweight object for the character. The coordinate position of the character within the document and its typographic style are extrinsic. They can be computed from the text layout algorithms and formatting commands in effect wherever the character appears. ©SoftMoore ConsultingSlide 4

5. Flyweight Pattern Intent: Use sharing to support large numbers of fine-grained objects efficiently. Applicability: Apply the Flyweight pattern when all of the following are true: –An application uses a large number of objects. –Storage costs are high because of the sheer quantity of objects. –Most object state can be made extrinsic. –Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed. –The application doesn’t depend on object identity. Since flyweight objects are shared, identity tests will return true for conceptually distinct objects. Slide 5©SoftMoore Consulting

6. Flyweight Pattern (continued) ©SoftMoore ConsultingSlide 6 Client Structure Flyweight operation(extrinsicState) UnsharedConcreteFlyweight intrinsicState extrinsicState operation(extrinsicState) ConcreteFlyweight intrinsicState operation(extrinsicState) * FlyweightFactory getFlyweight(key) if (flyweight[key] exists) return existing flyweight else create new flyweight add new flyweight to pool return new flyweight

7. Flyweight Pattern (continued) Participants Flyweight –declares an interface through which flyweights can receive and act on extrinsic state. ConcreteFlyweight –implements the Flyweight interface and adds storage for intrinsic state (if needed). –shareable because it does not store an extrinsic state. UnsharedConcreteFlyweight –implements the Flyweight interface. –stores both intrinsic and extrinsic state. –not shareable. Slide 7©SoftMoore Consulting

8. Flyweight Pattern (continued) Participants (continued) FlyweightFactory –creates and manages Flyweight objects. –ensures that flyweights are shared properly. –FlyweightFactory is essentially an Object Cache as discussed in the section on the Object Pool pattern. Client –maintains references to Flyweights. –computes or stores the extrinsic states of Flyweights Slide 8©SoftMoore Consulting

9. Flyweight Pattern (continued) Collaborations The state that a flyweight needs must be characterized as either intrinsic or extrinsic. Intrinsic state is stored with the ConcreteFlyweight object. Extrinsic state is stored or computed by client objects. Clients pass this extrinsic state to a flyweight when they invoke its operations. Clients should not instantiate ConcreteFlyweight objects directly. Clients should obtain ConcreteFlyweight objects from the FlyweightFactory to ensure that they are shared properly. ©SoftMoore ConsultingSlide 9

10. Flyweight Pattern (continued) Consequences Flyweights may introduce run-time costs associated with transferring, finding, and/or computing extrinsic state. Such costs should be offset by space savings, which increase as more flyweights are shared. Storage savings are a function of several factors: –the reduction in the total number of instances that comes from sharing –the amount of intrinsic state per object –whether extrinsic state is computed or stored If stored in a hierarchical structure (composite), flyweight leaf nodes cannot store a reference to their parent. ©SoftMoore ConsultingSlide 10

11. Flyweight Pattern (continued) Implementation The pattern’s applicability is determined largely by how easy it is to identify extrinsic state and remove it from shared objects. Ideally extrinsic state can be computed from a separate object, one with far smaller storage requirements. Since flyweights are shared, clients shouldn’t instantiate them directly. FlyweightFactory lets clients locate a particular flyweight. FlyweightFactory often uses an associative store (map) to let clients look up flyweights of interest. ©SoftMoore ConsultingSlide 11

12. Immutable Class A class is said to be immutable if its instances cannot be modified after construction. An immutable object is an instance of an immutable class. Guidelines for making a class immutable –Don’t provide methods that modify the object’s state. –Ensure that the class can’t be extended (e.g., make it final). –Make all fields private and final. Examples in Java –String –Wrapper classes (Integer, Double, Character, etc.) –BigInteger ©SoftMoore ConsultingSlide 12

13. Using Immutable Objects Immutable objects can be freely shared without the need to clone or copy. A client of an immutable object cannot make changes that affect other clients. Immutable objects are inherently thread-safe. They perform correctly when accessed from multiple threads with no additional synchronization or other coordination on the part of their clients. ©SoftMoore ConsultingSlide 13 “Classes should be immutable unless there is a very good reason to make them mutable” – Joshua Bloch

14. Flyweights and Immutable Objects Since multiple clients share access to flyweights, when one client changes the state of the flyweight, every client is affected by that change. If the flyweights are immutable, then they can be shared freely – clients cannot make changes that affect one another. Shared flyweights (flyweights with only the intrinsic state) should generally be immutable. Shared flyweights that are not immutable require special consideration to ensure that changes by one client don’t adversely affect other clients. ©SoftMoore ConsultingSlide 14

15. Flyweight Pattern in Java The factory method Boolean.valueOf(boolean) returns a shared instance – essentially a flyweight. Since strings in Java are immutable, they are easily shared. In Java, strings specified at compile-time are flyweights; i.e., strings with the same sequence of characters are automatically shared. String s1 = "flyweight"; String s2 = "flyweight"; System.out.println(s1 == s2); // prints true ©SoftMoore ConsultingSlide 15

16. Flyweight Pattern in Java (continued) The GUI classes in Java Swing provide a border factory that creates sharable flyweight borders. Border b1 = BorderFactory.createRaisedBevelBorder(); Border b2 = BorderFactory.createRaisedBevelBorder(); System.out.println(s1 == s2); // prints true ©SoftMoore ConsultingSlide 16

17. Example: Using Java Enums to Implement Flyweights public enum Coin { PENNY(1), NICKEL(5), DIME(10), QUARTER(25); Coin (int coinValue) { this.coinValue = coinValue; } public int coinValue() { return coinValue; } private final int coinValue; } ©SoftMoore ConsultingSlide 17

18. “Faking” Java Enums (Prior to Version 5 of Java) public final class Coin { private final int coinValue; public static final Coin PENNY = new Coin(1); public static final Coin NICKEL = new Coin(5); public static final Coin DIME = new Coin(10); public static final Coin QUARTER = new Coin(25); Coin (int coinValue) { this.coinValue = coinValue; } ©SoftMoore ConsultingSlide 18 (continued on next slide)

19. “Faking” Java Enums (continued) public int coinValue() { return coinValue; } ©SoftMoore ConsultingSlide 19

20. Value Types (Note: Not yet implemented in Java) Proposed future enhancements to the JVM and Java language include support for small, immutable, identityless value types. As envisioned, value types will combine the properties of both classes and primitive types. –live on the runtime stack rather than the heap (no identity) –think immutable records or structs. Value types would provide additional support for the implementation of the Flyweight Pattern. ©SoftMoore ConsultingSlide 20 “Codes like a class, works like an int!”

21. Related Patterns The flyweight pattern is often combined with the Composite pattern to implement a logically hierarchical structure in terms of a directed-acyclic graph with shared leaf nodes. It is often best to implement State and Strategy objects as flyweights. FlyweightFactory is an example of an Object Cache. (see slides on Object Pool Pattern) ©SoftMoore ConsultingSlide 21

22. References Flyweight pattern (Wikipedia) http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight (doFactory) http://www.dofactory.com/Patterns/PatternFlyweight.aspx Make your apps fly (David Geary – JavaWorld) http://www.javaworld.com/javaworld/jw-07-2003/jw-0725-designpatterns.html Enums in Java (One More Time) (John Moore – onJava.com, O’Reilly Media) http://onjava.com/pub/a/onjava/2003/04/23/jenum.html State of the Values (J. Rose, B. Goetz, G. Steele) http://cr.openjdk.java.net/~jrose/values/values-0.html ©SoftMoore ConsultingSlide 22