The Flyweight and Proxy Design Patterns

1
The Flyweight and Proxy Design Patterns

• Mike Heinrich and Philip Kunsik Cho

2
The Flyweight Pattern

• Used when class instances are fundamentally the
  same except for a few parameters
• Appropriate for small, fine-grained classes like
  individual characters or icons on a screen
• Provides a way to limit the proliferation of
  small, similar class instances by moving some of
  the class data outside the class and passing it
  in during various execution methods

3
Flyweight Terminology

• Flyweight is a shared object that can be used in
  multiple contexts simultaneously
• FlyweightFactory creates and manages flyweight
  objects
• ConcreteFlyweight implements the Flyweight
  interface and adds storage for the intrinsic
  state, if any
• Intrinsic data makes the instance unique
• Extrinsic data is the information passed in as
  arguments in method calls
• The Client references the Flyweight object

4
Flyweight Class Diagram
5
Flyweight Example
The Tone Generator Pool

• The problem
• The number of tones required by the switch is
  much smaller than the total number of
  subscribers.
• The solution
• The flyweight design pattern.

6
The Tone Generator Pool

• The tone generators correspond to the Flyweight
• The physical dial tone generator corresponds to
  the ConcreteFlyweight
• The tone generator pool corresponds to the
  FlyweightFactory
• The telephone switch corresponds to the Client

7
The Tone Generator Pool

• When a tone generator is requested, it is
  connected to the subscriber line.
• When the tone is no longer needed, it is
  disconnected so that another subscriber can use
  it.
• The switch maintains the reference to the
  flyweights.

8
The Tone Generator Pool

• Flyweight design is intended to save cost by
  reducing the number of tone generators required
  and by reducing the actual physical space
  required for equipment.
• An example of Flyweights intent, decrease the
  resources needed to instantiate objects with
  similar properties.

9
Flyweight Example (2)
Strategic Games

• The problem
• There are a number of soldiers in a strategic
  game, each of which corresponds to an object
  with graphics, data, and complicated method.
• The solution
• The flyweight design pattern.

10
Strategic Games

• Intrinsic data are graphics and methods that can
  be shared among all soldiers of the same type.
• Extrinsic data are the coordinates and the health
  points (or hit points) of each soldier, which is
  unique for each soldier.
• The game itself (Client) keeps track of extrinsic
  data of all soldiers, while the soldiers of the
  same type reference to the same object
  (ConcreteFlyweight) for any intrinsic data.

11
Related Patterns

• Often combined with the Composite pattern to
  implement a directed a-cyclic graph with shared
  leaf nodes.
• State and strategy should often be implemented as
  Flyweights.

12
The Flyweight Pattern Costs

• Flyweight introduces run-time costs associated
  with transferring, finding, and/or computing
  extrinsic states.
• Costs introduced by the Flyweight pattern are
  offset by space savings.
• The more intrinsic states there are, the more
  savings occur.

13
Flyweight Costs Continued

• Storage savings are influenced by several
  factors
• The reduction in the total number of instances
  that come from sharing.
• The amount of intrinsic states per object.
• Whether the extrinsic state is stored or
  computed.
• If a large number of extrinsic states must be
  computed, the space savings occur at the expense
  of computation time.

14
The Flyweight Pattern Conclusion

• Intended to use sharing to support large numbers
  of objects efficiently.
• Should be used in cases where many objects share
  similar data except for a few items, which can be
  passed through parameters.
• The intrinsic state is stored in the Flyweight
  and consists of information that is independent
  of the Flyweights context.
• The extrinsic state is stored in the client and
  consists of the parameters that are passed as
  parameters to the methods.
• Offsets run-time costs with storage savings.

15
The Proxy Pattern

• Useful in several different situations
• When an object takes a long time to load (virtual
  proxy).
• When an object is on a remote machine and loading
  it over a network may be slow (remote proxy).
• If an object has limited access rights, the proxy
  can authenticate a user (access proxy).

16
The Proxy Pattern

• Defers the cost of initialization and creation of
  an object until it is actually required
• Can be used to distinguish between requesting an
  instance of an object and the actual need to
  access it
• Useful in programs like web browsers and word
  processors to lay out text around images before
  the images are available
• Acts as a surrogate or placeholder

17
Proxy Class Diagram
18
Proxy Example
Proxy Example
Payment by Cheque
The problem An individual has cash in their
bank account but is not carrying cash with
them. The solution The proxy design pattern.
19
Payment by Cheque

• The cheque acts as a proxy for the funds in the
  account
• The funds are the RealSubject
• The client asks for payment through the cheque

20
Payment by Cheque

• The cheque is a virtual proxy in that it acts as
  funds
• The cheque is an access proxy in that only the
  person the cheque is payable to can access the
  funds paid by the cheque

21
Payment by Cheque

• Proxy allows the cheque to act as if it were
  actual funds, it is virtual cash
• Proxy ensures that only the person who the cheque
  is payable to can access the actual funds, the
  cheque acts as an access proxy
• The cheque could even be considered a remote
  proxy by allowing the person who cashes the
  cheque to access the funds before the cheque has
  cleared

22
Proxy Example (2)
Document Editor

• The problem
• When a document contains large bitmap images,
  it is slow to open the document.
• The solution
• The proxy design pattern.

23
Document Editor
aClient - documentsubject - Graphic
aVirtualProxyrealSubject
aRealSubjectbitmap image

• The real bitmap image object corresponds to
  RealSubject.
• The virtual proxy corresponds to Proxy.
• The graphic corresponds to Subject

24
Document Editor
aClient - documentsubject - Graphic
aVirtualProxyrealSubject
aRealSubjectbitmap image

• When the document is initially opened, the proxy
  is substituted instead of the real image.
• Only when the application needs to display the
  real image, it is loaded onto memory.
• VirtualProxy and RealSubject inherit the same
  abstract class, Graphic. Draw() method in
  RealSubject displays the image, while Draw() in
  VirtualProxy does not.

25
Related Patterns

• Adapter provides a different interface to the
  object it adapts, while proxy provides the same
  interface as its subject.
• Decorators can have similar implementations as
  proxies but they have a different purpose A
  decorator adds one or more responsibilities to an
  object, whereas a proxy controls access to an
  object.

26
The Proxy Pattern Costs

• There are no real costs associated with the Proxy
  pattern.
• Proxy allows for the saving of run-time costs by
  deferring processing of objects until it is
  actually required.

27
The Proxy Pattern Conclusion

• Proxy creates a level of indirection which can
  have multiple purposes.
• The three major uses are
• A remote proxy which hides the fact that an
  object resides in a different object space.
• A virtual proxy which can perform optimizations
  such as creating an object on demand.
• An access proxy which allows additional
  housekeeping tasks when an object is accessed.

28
References

• Cooper, James W. The Design Patterns Java
  Companion. IBM Thomas J. Watson Research Center.
  Yorkton Heights, NY, 1998. http//www.patterndepot
  .com/put/8/JavaPatterns.htm
• Duell, Michael. Non-Software Examples of Software
  Design Patterns. Accessed March 9, 2002, from
  http//www.agcs.com/supportv2/techpapers/patterns/
  papers/tutnotes/index.htm
• Erich Gamma, Richard Helm, Ralph Johnson, John
  Vlissides. Design Patterns Elements of Reusable
  Object-Oriented Software. Addison-Wesley
  Professional Computing Series, Addison-Wesley,
  Reading Mass. 1995.
• Kremer, Rob. Design Pattern Notes. Accessed March
  18, 2002, from http//sern.ucalgary.ca/courses/sen
  g/443/w02/patterns/index.html