17

FLYWEIGHT

This pattern was previously described in GoF95.

DESCRIPTION
Every object can be viewed as consisting of one or both of the following two
sets of information:

1. Intrinsic Information — The intrinsic information of an object is indepen-

dent of the object context. That means the intrinsic infor mation is the
common information that remains constant among different instances of a
given class. For example, the company information on a visiting card is
the same for all employees.
2. Extrinsic Information — The extrinsic information of an object is dependent
upon and varies with the object context. That means the extrinsic informa-
tion is unique for every instance of a given class. For example, the employee
name and title are extrinsic on a visiting card as this information is unique
for every employee.

Consider an application scenario that involves creating a large number of

objects that are unique only in terms of a few parameters. In other words, these
objects contain some intrinsic, invariant data that is common among all objects.
This intrinsic data needs to be created and maintained as part of every object
that is being created. The overall creation and maintenance of a large group of
such objects can be very expensive in terms of memory-usage and performance.
The Flyweight pattern can be used in such scenarios to design a more efficient
way of creating objects.
The Flyweight pattern suggests separating all the intrinsic common data into
a separate object referred to as a Flyweight object. The group of objects being
created can share the )O\ZHLJKW object as it represents their intrinsic state. This
eliminates the need for storing the same invariant, intrinsic information in every
object; instead it is stored only once in the form of a single )O\ZHLJKW object.
As a result, the client application can realize considerable savings in terms of the
memory-usage and the time.

© 2004 by CRC Press LLC

 g

Table 17.1 Flyweight Requirements

Serial
Number Description

1 There exists only one object of a given flyweight kind and is shared by
all the other appropriate objects.
2 Client objects should not be allowed to create flyweight instances
directly. At the same time, client objects should have a way of accessing
a required )O\ZHLJKW object when needed.

When the Flyweight pattern is applied, it is important to make sure that the
requirements listed in Table 17.1 are satisfied.

HOW TO DESIGN A FLYWEIGHT IN JAVA

One of the ways to design a flyweight in Java is to design it as a singleton similar
to the )O\ZHLJKW class in Figure 17.1.

DESIGN HIGHLIGHTS

䡲 The )O\ZHLJKW class is designed with a private constructor. This is to

prevent client objects from creating )O\ZHLJKW instances by directly
accessing its constructor.
䡲 In general, a singleton is expected to maintain only one instance of itself.
That is, the singleton nature is at the class type level. When a flyweight is
designed as a singleton, it exhibits the singleton nature at the flyweight
type level, not at the class type level. In other words, the singleton

1..*

Flyweight

lstFlyweight:HashMap
intrinsic_var_1
...
intrinsic_var_n

synchronized getFlyweight(flyweightType)
:Flyweight
-Flyweight()

Figure 17.1 Flyweight as a Singleton

© 2004 by CRC Press LLC

 y g

)O\ZHLJKW maintains a single instance of itself for every possible flyweight

type in the system. These flyweight objects are stored in the OVW)O\
ZHLJKW static variable. This can be viewed as a variation of the Singleton
pattern.

Whenever a client needs to create an instance of a given flyweight type, it

invokes the static JHW)O\ZHLJKW method, passing the required flyweight type
as an argument. The JHW)O\ZHLJKW method is designed as a synchronized class
level method to make it thread safe.
As part of its implementation of the JHW)O\ZHLJKW method, the )O\ZHLJKW
checks to see if an instance of itself corresponding to the requested flyweight
type already exists in the OVW)O\ZHLJKW +DVK0DS.

䡲 If it exists, the )O\ZHLJKW returns the existing )O\ZHLJKW object to the

client.
䡲 If it does not exist:
– The )O\ZHLJKW creates a new instance of itself corresponding to the
requested flyweight type and adds it to the flyweights list maintained
in the static OVW)O\ZHLJKW+DVK0DS variable. Because the JHW)O\
ZHLJKW method is defined within the )O\ZHLJKW class, it can access
its private constructor to create an instance of itself.
– It returns the newly created )O\ZHLJKW object to the client.

The flyweight design discussed so far meets the requirements listed in Table
17.1. In general, a flyweight is designed solely to represent the intrinsic state of
an object. Besides representing an object’s intrinsic state, the flyweight contains
the required data structures and the implementation to maintain different types
of singleton )O\ZHLJKW objects.
As an alternate design strategy, the responsibility of creating and maintaining
different singleton )O\ZHLJKW objects can be moved out of the )O\ZHLJKW to
a designated )O\ZHLJKW)DFWRU\. The )O\ZHLJKW can be designed as an inner
class of the )O\ZHLJKW)DFWRU\ class. Since the )O\ZHLJKW class is defined
with a private constructor, external objects are prevented from creating its instances
by directly invoking the constructor. But the )O\ZHLJKW)DFWRU\ can invoke
the )O\ZHLJKW class private constructor to create necessary )O\ZHLJKW objects.
This is because an outer class can access the private methods of its inner class.
In the new design (Figure 17.2), both the data structure (OVW)O\ZHLJKW
+DVK0DS) and the behavior (JHW)O\ZHLJKW method) related to the creation
and maintenance of singleton )O\ZHLJKW objects are moved from the )O\
ZHLJKW class to the )O\ZHLJKW)DFWRU\class. The )O\ZHLJKW instances are
used solely to represent an object’s intrinsic state.
Whenever a client needs to create an instance of a given flyweight type, it
invokes, the JHW)O\ZHLJKW method on the singleton )O\ZHLJKW)DFWRU\
instance, passing the required flyweight type as an argument. The singleton
)O\ZHLJKW)DFWRU\ object maintains the list of existing )O\ZHLJKW objects in
the OVW)O\ZHLJKW instance variable.

© 2004 by CRC Press LLC

 g

-$SingleInstance

FlyweightFactory

lstFlyweight:HashMap
factory:FlyweightFactory

synchronized getFlyweight(flyweightType)
:Flyweight
getInstance():FlyweightFactory

Flyweight

intrinsic_var_1
...
intrinsic_var_n

-Flyweight()

Figure 17.2 Flyweight as an Inner Class inside a Singleton Factory

As part of its implementation of the JHW)O\ZHLJKW method, the )O\

ZHLJKW)DFWRU\checks to see if an instance of the )O\ZHLJKW corresponding
to the requested flyweight type already exists in the OVW)O\ZHLJKW+DVK0DS.

䡲 If it exists, the )O\ZHLJKW)DFWRU\ returns the existing )O\ZHLJKW

object to the client.
䡲 If it does not exist:
– The )O\ZHLJKW)DFWRU\ creates a new instance of the )O\ZHLJKW
corresponding to the requested flyweight type and adds it to the fly-
weights list maintained in the OVW)O\ZHLJKW +DVK0DS variable.
– It returns the newly created )O\ZHLJKW object to the client.

The )O\ZHLJK)DFWRU\ is designed as a singleton to prevent client objects

from creating multiple instances of the )O\ZHLJKW)DFWRU\, thereby creating
multiple instances of a given flyweight kind.
Once the requested )O\ZHLJKW object is received, the client can either:

䡲 Create an object with the exclusive extrinsic data and associate the )O\
ZHLJKW object with it. This approach still results in the creation of a large
number of objects but the design becomes more efficient as the intrinsic
data is not duplicated in every object. Instead, it is kept inside a single
shared )O\ZHLJKW object (Design Approach I in the following example).

© 2004 by CRC Press LLC

 y g

䡲 Send the extrinsic data as part of a method call to the )O\ZHLJKW object.
This approach results in the creation of few objects with no duplication
(Design Approach II in the following example).

EXAMPLE
To demonstrate the use of the Flyweight pattern, let us design an application that
prints out the data for visiting cards of all the employees of a large organization
with four major divisional offices. A typical visiting card can be assumed to have
the following layout:

1DPH RI WKH (PSOR\HH!!

7LWOH!!
&RPSDQ\ 1DPH!!
'LYLVLRQDOB2IILFHB$GGUHVVB/LQHV!!
&LW\!!6WDWH!!=LS&RGH!!

From the visiting card data layout, it can be observed that:

䡲 The name and the title are unique for every employee and can be
considered as the extrinsic data.
䡲 The company name remains the same for all employees and every
employee working under a divisional office is given the same divisional
office address. Therefore the company name and division address part of
a visiting card can be treated as the intrinsic data.

One of the simplest strategies for designing this example application is to

create a 9&DUGclass representing a visiting card as in Figure 17.3. The SULQW
method can be implemented to display the visiting card data.

VCard

name:String
title:String
company:String
address:String
city:String
state:String
zip:String

print()

Figure 17.3 Visiting Card: Class Representation

© 2004 by CRC Press LLC

 g

Usually, there will be thousands of employees in a large organization and

hence the application may need to create thousands of 9&DUG objects. As
discussed earlier, the address part of the 9&DUG class remains constant for all
employees working under a given divisional office. Hence, adapting the class
representation depicted in Figure 17.3 could lead to duplicate data being created
and maintained as part of every new 9&DUG instance created. Using the Flyweight
pattern, the need for storing the duplicate data can be eliminated.

DESIGN APPROACH I
In this approach, the extrinsic data is represented as an object and configured
with a )O\ZHLJKW object representing its intrinsic data.
Applying the Flyweight pattern, all the intrinsic data can be moved out of the
9&DUG class into a separate )O\ZHLJKW class. Let us define an interface )O\
ZHLJKW,QWU to be implemented by the )O\ZHLJKW class representing the
visiting card intrinsic data.

SXEOLF LQWHUIDFH )O\ZHLJKW,QWU ^

SXEOLF 6WULQJ JHW&RPSDQ\ 
SXEOLF 6WULQJ JHW$GGUHVV 
SXEOLF 6WULQJ JHW&LW\ 
SXEOLF 6WULQJ JHW6WDWH 
SXEOLF 6WULQJ JHW=LS 
`

As we discussed under the “How to Design a Flyweight in Java” section earlier,

let us define a singleton )O\ZHLJKW)DFWRU\ (Listing 17.1) with the responsi-
bility of creating and maintaining single instances of different )O\ZHLJKW objects
corresponding to different divisions.
The actual )O\ZHLJKW class can be defined within the )O\ZHLJKW)DFWRU\
as an inner class (Figure 17.4).
The design highlights of the concrete )O\ZHLJKW and the )O\ZHLJKW)DF
WRU\ classes are as follows:

䡲 The concrete )O\ZHLJKW class is designed with a private constructor to

prevent external objects from creating Flyweight instances directly by
invoking its constructor.
䡲 The concrete )O\ZHLJKW class is designed as an inner class within the
)O\ZHLJKW)DFWRU\ to allow the )O\ZHLJKW)DFWRU\ to invoke its
private constructor.
䡲 The )O\ZHLJKW)DFWRU\ is responsible for creating and managing dif-
ferent Flyweight instances. It maintains a list of different )O\ZHLJKW
objects inside the OVW)O\ZHLJKW +DVK0DS instance variable. When a
client requests a )O\ZHLJKW object corresponding to a specific division,
the )O\ZHLJKW)DFWRU\ checks the list of existing )O\ZHLJKW objects
to see if it is already created. If it is already created and available in the
list, the )O\ZHLJKW)DFWRU\ returns the existing )O\ZHLJKW object. If

© 2004 by CRC Press LLC

 y g

Listing 17.1 Singleton )O\ZHLJKW)DFWRU\ Class with Inner )O\ZHLJKW Class

VLQJOHWRQ )O\ZHLJKW )DFWRU\

SXEOLF FODVV )O\ZHLJKW)DFWRU\ ^
SULYDWH +DVK0DS OVW)O\ZHLJKW
SULYDWH VWDWLF )O\ZHLJKW)DFWRU\ IDFWRU\
QHZ )O\ZHLJKW)DFWRU\ 
SULYDWH )O\ZHLJKW)DFWRU\ ^
OVW)O\ZHLJKW  QHZ +DVK0DS 
`
SXEOLF V\QFKURQL]HG )O\ZHLJKW,QWU JHW)O\ZHLJKW
6WULQJ GLYLVLRQ1DPH  ^
LI OVW)O\ZHLJKWJHW GLYLVLRQ1DPH   QXOO  ^
)O\ZHLJKW,QWU IZ  QHZ )O\ZHLJKW GLYLVLRQ1DPH 
OVW)O\ZHLJKWSXW GLYLVLRQ1DPH IZ 
UHWXUQ IZ
` HOVH ^
UHWXUQ )O\ZHLJKW,QWU  OVW)O\ZHLJKWJHW GLYLVLRQ1DPH 
`
`
SXEOLF VWDWLF )O\ZHLJKW)DFWRU\ JHW,QVWDQFH ^
UHWXUQ IDFWRU\
`
,QQHU IO\ZHLJKW FODVV
SULYDWH FODVV )O\ZHLJKW LPSOHPHQWV )O\ZHLJKW,QWU ^
SULYDWH 6WULQJ FRPSDQ\
SULYDWH 6WULQJ DGGUHVV
SULYDWH 6WULQJ FLW\
SULYDWH 6WULQJ VWDWH
SULYDWH 6WULQJ ]LS
SULYDWH YRLG VHW9DOXHV 6WULQJ FPS 6WULQJ DGGU
6WULQJ FW\ 6WULQJ VW 6WULQJ ]S  ^
FRPSDQ\  FPS
DGGUHVV  DGGU
FLW\  FW\
VWDWH  VW
]LS  ]S
`

(continued)

© 2004 by CRC Press LLC

 g

Listing 17.1 Singleton )O\ZHLJKW)DFWRU\ Class with Inner )O\ZHLJKW Class

(Continued)

SULYDWH )O\ZHLJKW 6WULQJ GLYLVLRQ  ^

YDOXHV DUH KDUG FRGHG
IRU VLPSOLFLW\
LI GLYLVLRQHTXDOV 1RUWK ^
VHW9DOXHV &03µDGGUµ FW\µVWµ 
`
LI GLYLVLRQHTXDOV 6RXWK ^
VHW9DOXHV &03µDGGUµ FW\µVWµ 
`
LI GLYLVLRQHTXDOV (DVW ^
VHW9DOXHV &03µDGGUµ FW\µVWµ 
`
LI GLYLVLRQHTXDOV :HVW ^
VHW9DOXHV &03µDGGUµ FW\µVWµ 
`
`
SXEOLF 6WULQJ JHW&RPSDQ\ ^
UHWXUQ FRPSDQ\
`
SXEOLF 6WULQJ JHW$GGUHVV ^
UHWXUQ DGGUHVV
`
SXEOLF 6WULQJ JHW&LW\ ^
UHWXUQ FLW\
`
SXEOLF 6WULQJ JHW6WDWH ^
UHWXUQ VWDWH
`
SXEOLF 6WULQJ JHW=LS ^
UHWXUQ ]LS
`
`HQG RI )O\ZHLJKW
`HQG RI )O\ZHLJKW)DFWRU\

not, the )O\ZHLJKW)DFWRU\creates the requested )O\ZHLJKW object,

stores it inside the list and returns it to the client. Subsequently, when a
client object requests a flyweight corresponding to the same division, the
)O\ZHLJKW object is not created. Instead, the corresponding )O\ZHLJKW

© 2004 by CRC Press LLC

 y g

-$SingleInstance

FlyweightFactory

lstFlyweight:HashMap
factory:FlyweightFactory

synchronized getFlyweight(division:String)
:FlyweightIntr
getInstance():FlyweightFactory

Flyweight

company:String
address:String
city:String
<<interface>> state:String
FlyweightIntr zip:String

getCompany():String getCompany():String
getAddress():String getAddress():String
getCity():String getCity():String
getState():String getState():String
getZip():String getZip():String

Figure 17.4 )O\ZHLJKW)DFWRU\ with an Inner )O\ZHLJKW Class

object from the OVW)O\ZHLJKW +DVK0DS instance variable is returned

to the client.
䡲 The )O\ZHLJKW)DFWRU\ is designed as a singleton so that it guarantees
the uniqueness of )O\ZHLJKW objects.

After the intrinsic data is removed, the extrinsic data still remains within the
9&DUG class (Listing 17.2). As part of its constructor, the 9&DUG accepts a
)O\ZHLJKW instance representing its intrinsic data. The SULQW method displays
extrinsic data from the 9&DUG and intrinsic data from the associated )O\ZHLJKW
object.
With these objects in place, in order to print the visiting card data, a client
object such as )O\ZHLJKW7HVW (Listing 17.3):

1. Creates an instance of the singleton )O\ZHLJKW)DFWRU\.

2. Requests an appropriate )O\ZHLJKW object (for every employee) by invok-
ing the JHW)O\ZHLJKW method on the singleton )O\ZHLJKW)DFWRU\
instance, passing the division that the employee works for as an argument.
In response, the )O\ZHLJKW)DFWRU\ returns a )O\ZHLJKW instance
corresponding to the specified division. Since the example organization is

© 2004 by CRC Press LLC

 g

Listing 17.2 9&DUG Class Using a )O\ZHLJKW Object to Represent the Intrinsic Data

SXEOLF FODVV 9&DUG ^

6WULQJ QDPH
6WULQJ WLWOH
)O\ZHLJKW,QWU REM):
SXEOLF 9&DUG 6WULQJ Q 6WULQJ W )O\ZHLJKW,QWU IZ  ^
QDPH  Q
WLWOH  W
REM):  IZ
`
SXEOLF YRLG SULQW ^
6\VWHPRXWSULQWOQ QDPH 
6\VWHPRXWSULQWOQ WLWOH 
6\VWHPRXWSULQWOQ REM):JHW$GGUHVV    
REM):JHW&LW\    
REM):JHW6WDWH    
REM):JHW=LS 
6\VWHPRXWSULQWOQ  ³ ³ ³ ³ ³ ³ ³ ³  
`
`

assumed to have only four divisions, there will be a maximum of four

)O\ZHLJKW objects created when the application is run.
3. Receives the requested )O\ZHLJKW object and then associates the Fly-
weight with the 9&DUG instance representing the extrinsic data by passing
the )O\ZHLJKW object as an argument to the 9&DUG constructor.

Figure 17.5 shows the overall class association.

The following sequence diagram in Figure 17.6 depicts the message flow during
the creation and display of the visiting card data of an employee working for a
specific divisional office.
This approach requires the creation of a 9&DUG object for every employee in
addition to the four )O\ZHLJKW objects. The fact that the intrinsic data is not
duplicated in every 9&DUG object results in savings in terms of the memory usage
and the time it takes to create objects.

DESIGN APPROACH II
Extrinsic data passed to the flyweight as part of a method call and was not
represented as an object (Listing 17.4).
This design approach requires the following two changes to the application
design discussed in Design Approach I.

© 2004 by CRC Press LLC

 y g

Listing 17.3 Client )O\ZHLJKW7HVW Class

SXEOLF FODVV )O\ZHLJKW7HVW ^

SXEOLF VWDWLF YRLG PDLQ 6WULQJ>@ DUJV  WKURZV ([FHSWLRQ ^
9HFWRU HPS/LVW  LQLWLDOL]H 
)O\ZHLJKW)DFWRU\ IDFWRU\
)O\ZHLJKW)DFWRU\JHW,QVWDQFH 
IRU LQW L   L  HPS/LVWVL]H  L  ^
6WULQJ V  6WULQJ  HPS/LVWHOHPHQW$W L 
6WULQJ7RNHQL]HU VW  QHZ 6WULQJ7RNHQL]HU V µ 
6WULQJ QDPH  VWQH[W7RNHQ 
6WULQJ WLWOH  VWQH[W7RNHQ 
6WULQJ GLYLVLRQ  VWQH[W7RNHQ 
)O\ZHLJKW,QWU IO\ZHLJKW
IDFWRU\JHW)O\ZHLJKW GLYLVLRQ 
DVVRFLDWH WKH IO\ZHLJKW
ZLWK WKH H[WULQVLF GDWD REMHFW
9&DUG FDUG  QHZ 9&DUG QDPH WLWOH IO\ZHLJKW 
FDUGSULQW 
`
`
SULYDWH VWDWLF 9HFWRU LQLWLDOL]H ^
«
«
`
`

䡲 The print method:

– Needs to be moved from the 9&DUG class to the )O\ZHLJKW class.
– Signature needs to be changed from

SXEOLF YRLG SULQW

to

SXEOLF YRLG SULQW 6WULQJ QDPH 6WULQJ WLWOH

in order to accept the extrinsic data as arguments.

䡲 Should be implemented to display the extrinsic data passed to it along
with the intrinsic data it represents.

© 2004 by CRC Press LLC

 g

-$SingleInstance

FlyweightFactory
<<Interface>>
FlyweightIntr
lstFlyweight:HashMap
factory:FlyweightFactory
getCompany():String
getAddress():String
getFlyweight(division:String) getCity():String
:FlyweightIntr getState():String
getInstance():FlyweightFactory getZip():String

VCard
<<creates>>

objFW:FlyweightIntr Flyweight

getCompany():String
<<creates>> getAddress():String
getCity():String
FlyweightTest getState():String
getZip():String
flyweight:FlyweightIntr

Figure 17.5 Design Approach I: Class Association

FlyweightTest FlyweightFactory Flyweight VCard

getInstance()

getFlyweight(division:String)

create()

create(name:String, title:String, objFW:Flyweight)

print()

Figure 17.6 Message Flow: Design Approach I

© 2004 by CRC Press LLC

 y g

Listing 17.4 Revised )O\ZHLJKW)DFWRU\ Class

SXEOLF LQWHUIDFH )O\ZHLJKW,QWU ^

SXEOLF 6WULQJ JHW&RPSDQ\ 
SXEOLF 6WULQJ JHW$GGUHVV 
SXEOLF 6WULQJ JHW&LW\ 
SXEOLF 6WULQJ JHW6WDWH 
SXEOLF 6WULQJ JHW=LS 
SXEOLF YRLG SULQW 6WULQJ QDPH 6WULQJ WLWOH 
`
VLQJOHWRQ )O\ZHLJKW )DFWRU\
SXEOLF FODVV )O\ZHLJKW)DFWRU\ ^
«
«
,QQHU IO\ZHLJKW FODVV
SULYDWH FODVV )O\ZHLJKW LPSOHPHQWV )O\ZHLJKW,QWU ^
«
«
SXEOLF YRLG SULQW 6WULQJ QDPH 6WULQJ WLWOH  ^
6\VWHPRXWSULQWOQ QDPH 
6\VWHPRXWSULQWOQ WLWOH 
6\VWHPRXWSULQWOQ JHW$GGUHVV JHW&LW\ 
  JHW6WDWH     JHW=LS 
6\VWHPRXWSULQWOQ  ³ ³ ³ ³ ³ ³ ³ ³  
`
`HQG RI )O\ZHLJKW
`HQG RI )O\ZHLJKW)DFWRU\

䡲 9&DUG class:
– Since the extrinsic data is to be passed to the )O\ZHLJKW object and
hence the 9&DUG class is no longer needed, this class can be removed
from the design.

In the new design, the client )O\ZHLJKW7HVW (Listing 17.5):

䡲 First creates an instance of the singleton )O\ZHLJKW)DFWRU\. The design

and implementation of the )O\ZHLJKW)DFWRU\ remains the same as in
Design Approach I.
䡲 For every employee, the application requests the )O\ZHLJKW)DFWRU\
for an appropriate )O\ZHLJKW object by passing the division that the
employee works for.

© 2004 by CRC Press LLC

 g

Listing 17.5 Client )O\ZHLJKW7HVW Class

SXEOLF FODVV )O\ZHLJKW7HVW ^

SXEOLF VWDWLF YRLG PDLQ 6WULQJ>@ DUJV  WKURZV ([FHSWLRQ ^
9HFWRU HPS/LVW  LQLWLDOL]H 
)O\ZHLJKW)DFWRU\ IDFWRU\
)O\ZHLJKW)DFWRU\JHW,QVWDQFH 
IRU LQW L   L  HPS/LVWVL]H  L  ^
6WULQJ V  6WULQJ  HPS/LVWHOHPHQW$W L 
6WULQJ7RNHQL]HU VW  QHZ 6WULQJ7RNHQL]HU V µ 
6WULQJ QDPH  VWQH[W7RNHQ 
6WULQJ WLWOH  VWQH[W7RNHQ 
6WULQJ GLYLVLRQ  VWQH[W7RNHQ 
)O\ZHLJKW,QWU IO\ZHLJKW
IDFWRU\JHW)O\ZHLJKW GLYLVLRQ 
SDVV WKH H[WULQVLF GDWD
DV SDUW RI D PHWKRG FDOO
IO\ZHLJKWSULQW QDPH WLWOH 
`
`
«
«
`

䡲 Once the requested )O\ZHLJKW object is received, the client invokes the
print method on the )O\ZHLJKW object by passing the extrinsic data
(employee name and title).

Figure 17.7 shows the class association in the revised design.

The sequence diagram in Figure 17.8 depicts the message flow in the new
design during the creation and display of the visiting card data of an employee
working for a specific divisional office.
Because the extrinsic data is not designed as an object, this approach requires
the creation of only four )O\ZHLJKW objects, each corresponding to a divisional
office with no duplication. This substantially reduces the memory usage and the
time required for the object creation.

PRACTICE QUESTIONS

1. Let us consider an online job site that receives XML data files from different
employers with current openings in their organizations. When the number
of vacancies is small, employers can enter details online. When the number

© 2004 by CRC Press LLC

 y g

-$SingleInstance

FlyweightFactory Flyweight

lstFlyweight:HashMap getCompany():String
factory:FlyweightFactory getAddress():String
getCity():String
getState():String
getFlyweight(division:String)
getZip():String
:FlyweightIntr
print(name:String,
getInstance():FlyweightFactory
title:String)

<<Interface>>
FlyweightIntr

getCompany():String
FlyweightTest getAddress():String
<<uses>> getCity():String
flyweight:FlyweightIntr getState():String
getZip():String
print(name:String,
title:String)

Figure 17.7 Design Approach II: Class Association

FlyweightTest FlyweightFactory Flyweight

getInstance()

getFlyweight(division:String)

create()

print(name:String, title:String)

Figure 17.8 Message Flow: Design Approach II

© 2004 by CRC Press LLC

 g

of vacancies is large, employers upload details in the form of an XML file.

Once the XML file is received, it needs to be parsed and processed. Let us
assume the XML file to have the following details:
a. Job title
b. Minimum qualifications
c. Medical insurance
d. Dental insurance
e. Vision care
f. 401K
g. Minimum number of hours of work
h. Paid vacation
i. Employer name
j. Employer address

In general, details from (c) through (j) are all considered to be the same
for all jobs posted by a given employer. Apply the Flyweight pattern to
design the process of parsing the input XML file and creating different
-RE objects.
2. A computer user in a typical organization is associated with a user account.
A user account can be part of one or more groups. Permissions on different
resources (such as servers, printers, etc.) are defined at the group level.
Users get all the permissions defined for all groups that their accounts are
part of. Let us consider an organization with three different user groups —
$GPLQLVWUDWRUV, )LHOG2IILFHUV and 6DOHV5HSV. Further assume
that the organization is in the process of migrating user accounts from one
server to a different server environment. As part of this process, all user
accounts are first exported to an XML file as follows.

8VHUV!
8VHU!
8VHU1DPH!3.XFKDQD8VHU1DPH!
3DVVZRUG!3.XFKDQD3DVVZRUG!
*URXS!)LHOG2IILFHUV*URXS!
3HUPLVVLRQV!
3HUPLVVLRQ!3HUP3HUPLVVLRQ!
3HUPLVVLRQ!3HUP3HUPLVVLRQ!
3HUPLVVLRQV!
8VHU!
8VHU!
8VHU1DPH!9.XFKDQD8VHU1DPH!
3DVVZRUG!9.XFKDQD3DVVZRUG!
*URXS!6DOHV5HSV*URXS!
3HUPLVVLRQV!
3HUPLVVLRQ!3HUP3HUPLVVLRQ!
3HUPLVVLRQ!3HUP3HUPLVVLRQ!

© 2004 by CRC Press LLC

 y g

3HUPLVVLRQV!
8VHU!
«
«
8VHUV!

It is to be noted that permissions for all accounts in a given group are the
same. This can be considered as the intrinsic data. The user name and the
password details vary from user to user and should be treated as extrinsic
data.
User accounts in the new server environment are created using the
exported XML file. Make any necessary assumptions and design an appli-
cation using the Flyweight pattern to parse the XML file to create different
user account objects.

© 2004 by CRC Press LLC