Based on GoF Book

1. Flyweight Pattern
Structural Pattern

2. Motivation
 You want to draw a forest of trees!
 How would you implement this?
 Millions of tree objects in the program?
 Memory constraint
 What is the optimal solution?
 Can we implement it so that we create only 1 tree
object?
2

3. Flyweight Pattern
 That’s where flyweight comes in!
 If the objects you create have so much common
properties (like trees, only positions are different).
 The activity diagram may be like this with only one
instance.
 Then, we have to store positions somewhere!
 Client can do this for us.
3

4. Definition
 Flyweight pattern is a pattern for sharing objects,
where each instance does not contain its own
state but stores it externally.
 This allows efficient sharing of objects to save
space when there are many instances but only a
few different types.
4

5. Text Document Example
 You want to hold a text document with so many
customizations as style.
 Each letter in with a different object?
 Creating the letter ‘E’, may be already there before,
but with a different style!
 So we will have a
CharFactory to return
us the already created
instance OR creates
it from scratch!
5

6. Structure
6

7. Participants
 Flyweight
 Letter as an abstract class
 SharedConcreteFlyweight
 LetterA
 UnsharedConcreteFlyweight
 Not all flyweights must be shared!
 Row information for example
 FlyweightFactory
 Creates and manages flyweights (Character factory)
 Client
 The styles are stored here, also call to factory
7

8. Intrinsic & Extrinsic States
 From course slides (7.Quality of Design)
 B is extrinsic to A if A can be fully defined with no
notion of B
 E.g., class Dog is extrinsic to class Person
 B is intrinsic to A if B captures some characteristics
inherent to A
 E.g., class Date is intrinsic to class Person (by date of
birth)
 What is with us?
 Extrinsic states may be stored in client!
 Intrinsic states may be stored in flyweight itself!
8

9. Sequence Diagram
9

10. Applicability
 Use flyweight pattern iff:
 You will use large number of objects.
 You want to reduce storage costs.
 Most of object states can be extrinsic.
 Many group of objects > Fewer shared objects with states
 App doesnot care object identity.
 Ex: Drawing lots of circles
with different colors and sizes
10

11. Consequences
 Run time costs
 Client is responsible for extrinsic states (storing, fetching
etc)
 Normally they are part of the object.
 Space saving
 Will increase as more flyweights are shared.
 How much you share, that much you save space!
 Factory
 Flyweight must be created only via factory!
11

12. Demo
 Circle Drawing. (ref at the end)
 We want to draw10000 circles in 6 different colors.
 Circles have color in common. (intrinsic state)
 Position and radius information is given as extrinsic
state. (randomly generated)
12

13. Implementation Issues
 Storing extrinsic states can be tricky
 An object structure for extrinsic states
 In text document example, you can store a map of typographic
information in seperate structure, instead of storing the font and
style information with each object.
 This map can keep track of numbers of characters with same
attribute.
 Accessing a specific object
 We have to design the system
according to that need.
 In drawing tree example,
we just draw and go.
 We can make the access
with a pointer.
13

14. Implementation Issues
 Extrinsic states can be stored but what about we
want to change the intrinsic state of a flyweight?
 Modify the factory as to create new flyweights with a
different intrinsic state also.
 Not so efficient, slowly breaking the flyweight pattern.
 UnsharedConcreteFlyweight is normally a totally
different object but we can also make them sharable
via factory.
 If they become sharable later, the oldly created ones
should be added to factory.
14

15. Relation with Other Patterns
 You can combine Composite pattern with Flyweight.
 Each UnsharedConcreteFlyweight may be
component with SharedConcreteFlyweights as
children.
 In text document:
Rows are components
or UnsharedConcFly.
Letters are leafs
or SharedConcFly.
15

16. Relation with Other Patterns – cont’d
 FlyweightFactory produces flyweights as in Factory
Method.
 No abstract Creator (but we can)
 FlyweightFactory is the ConcreteCreator.
 Flyweight is Product.
 Subclasses of Flyweight is ConcreteProducts.
 It only looks for an already created instance instead of
returning new ConcreteProduct() immediately.
16

17. Relation with Other Patterns – cont’d
 In State Pattern, you can share states with Flyweight
Pattern.
 Flyweight is State.
 SharedConcreteFlyweight is ConcreteState.
 Client is Context.
 With that way, Context can share states if the state is
already created.
 Handle method may
also get extrinsic
state as parameter.
17

18. Relation with Other Patterns – cont’d
 The same logic works with the Strategy Pattern.
 Strategy can be shared, and algorithm can be run with
only different inputs (extrinsic state).
 The algorithm itself is the intrinsic state.
 Difference is: flyweights can be used in many context
but strategy is in one context.
18

19. Practical Example
 Strings in Java language.
 If you don’t explicitly construct a string and put the
value with assignment operator, they will be same.
 Actually Java has another method called intern for
sharing strings.
19

20. Thanks
Questions?
20

21. References
 GoF Design Patterns Book
 Definition from: C# design patterns, James cooper
 http://www.dofactory.com/Patterns/PatternFlyweight.
aspx#_self1
 http://fc07.deviantart.net/fs32/f/2008/218/8/7/Pine_fo
rest_by_softwalls.jpg
 Oreilly Head First: Design Patterns Book
 Fry of Futurama for Questions Picture
 Demo:
http://www.javacamp.org/designPattern/flyweight.htm
l
 http://javatechniques.com/public/java/docs/basics/stri
ng-equality.html
21