Software design: Lecture 37 - Sheraz Pervaiz

Software design - Lecture 37. The main topics covered in this chapter include: flyweight design pattern; motivation for flyweight design pattern; intrinsic information - shareable; extrinsic information – not shareable; heavyweight object nightmare;...

Lecture : 37

Flyweight Design Pattern

At time some programs require a large number of objects that have some shared state among them

Every object can be viewed as consisting of one or both 

of the following two sets of information:

i Intrinsic

ii Extrinsic

The  intrinsic  information  of  an  object  is  independent  of the  object  context.  That  means  the  intrinsic  information 

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

Shareable

The extrinsic information of an object is dependent upon and  varies  with  the  object  context.  That  means  the extrinsic  information  is  unique  for  every  instance  of  a given class

For example, the employee id , 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  intent  of  this  pattern  is  to  use  sharing  to  support  a large  number  of  objects  that  have  part  of  their  internal state in common where the other part of state can vary

•

“Facilitates the reuse of many fine grained 

objects, making the utilization of large 

numbers of objects more efficient”

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 flyweight object

As a result, the client application can realize considerable savings in terms of the memory­usage and the time

Connection Pooling

A connection  pool is  a cache of database connections maintained  so  that  the  connections  can  be reused  when  future  requests  to  the  database  are required.  Connection  pools  are  used  to  enhance  the performance  of  executing  commands  on  a  database. Opening and maintaining a database connection for each user,  especially  requests  made  to  a  dynamic  database­driven website application,  is  costly  and  wastes resources. 

In connection pooling, after a connection is created, it is placed in the pool and it is used over again so that a new connection  does  not  have  to  be  established.  If  all  the connections  are  being  used,  a  new  connection  is  made and  is  added  to  the  pool.  Connection  pooling  also  cuts down  on  the  amount  of  time  a  user  must  wait  to establish a connection to the database

Class Diagram

 Flyweight ­  Declares  an  interface  through  which flyweights can receive and act on extrinsic state.

Concrete  Flyweight ­  Implements  the  Flyweight 

interface and stores intrinsic state. A Concrete Flyweight object  must  be  sharable.  The  Concrete  flyweight  object must maintain state that it is intrinsic to it, and must be able to manipulate state that is extrinsic

 Flyweight Factory ­ The factory creates and manages flyweight objects. In addition the factory ensures sharing 

of the flyweight objects. The factory maintains a pool of different flyweight objects and returns an object from the pool  if  it  is  already  created,  adds  one  to  the  pool  and returns it in case it is new

Client ­  A  client  maintains  references  to  flyweights  in 

addition to computing and maintaining extrinsic state

Flow of the application

 A client needs a flyweight object; it calls the factory 

to  get  the  flyweight  object.  The  factory  checks  a  pool of flyweights to determine if a flyweight object 

of the requested type is in the pool, if there is, the  reference  to  that  object  is  returned.  If  there  is  no  object  of  the  required  type,  the  factory  creates  a  flyweight of the requested type, adds it to the pool,  and returns a reference to the flyweight. 

 The flyweight maintains intrinsic state (state that 

is shared among the large number of objects that 

we have created the flyweight for) and provides  methods to manipulate external state (State that  vary  from  object  to  object  and  is  not  common  among the objects we have created the flyweight  for).

 Factory and Singleton patterns ­ 

Flyweights are usually created using a factory and  the singleton is applied to that factory so that for  each  type  or  category  of  flyweights  a  single  instance is returned.

Example Scenario

In  a  war  game  ,  there  is  a  large  number  of  soldier objects;  a  soldier  object  maintain  the  graphical representation  of  a  soldier,  soldier  behavior  such  as motion,  and  firing  weapons,  in  addition  soldiers  health and location on the war terrain. 

Creating a large number of soldier objects is a necessity 

however it  would incur  a huge  memory cost.  Note that 

although the representation and behavior of a soldier 

is the same their health and location can vary greatly.

client  maintains  its  internal  state  which  is  extrinsic to the soldier flyweight. And Although 5  clients have been instantiated only one flyweight  Soldier has been used.