Java Mailing List Archive

http://www.junlu.com/

Home » Home (12/2007) » J2EE Pattern »

Re: Flyweight vs Value Object

Stasko, Roger

2003-08-22


The classic Value Object pattern is quite different from the G04
Flyweight Pattern. Both are based on immutability, but the motivations,
uses, and implementations are completely different.

A Money object as the typical example of the value object pattern -- an
instance of Money represents a particular immutable value. We make
value objects immutable to communicate what happens when the value is
changed (we get a new object so anybody holding a reference to the old
object are not affected by this change).

A CurrencyType object (UsDollars, CanadianDollars, Euros, MexicanPesos,
etc.) is an example of the flyweight pattern. If we were to implement
CurrencyType with the value object pattern, every instance of Money
would have it's own instance of CurrencyType, so there could be a huge
number of identical immutable objects in our system. The Flyweight
patterns shows us how all of these non-changeable, immutable objects can
share a single instance of USDollars, enabling a huge reduction in the
overall number of CurrencyType instances in our system at any given
time.

-----Original Message-----
From: Dirk Riehle [mailto:java.sun.com@(protected)]
Sent: Friday, August 22, 2003 12:44 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Flyweight vs Value Object


I agree these are different patterns. They are related though: The
Flyweight Pattern can serve as an efficient implementation of the Value
Object pattern.

The Value Object pattern is abstract in the sense that it tells you to
do proper domain modeling and capture as Value Objects what are values
from a modeling perspective.

Typically, you implement Value Objects as immutable objects/Flyweight
Pattern. (Sorry, my copy of the GOF book is in storage so I'm not sure
the match Immutable/Flyweight is 100%).

But not always. You can use the Body/Handle idiom, copy on write, etc.

We wrote up such implementation techniques for anyone interested at:

http://www.riehle.org/computer-science/research/1998/ubilab-tr-1998-10-1
.html

Also, there is always JValue if you are interested in doing it in Java:

http://www.jvalue.org

Dirk


At 8/21/2003 -0300, tetsuo wrote:
>It simply isn't the pattern described by the GoF. The intent of the
>Flyweight design pattern is to "use sharing to support large numbers of

>fine-grained objects efficiently."
>
>An example of it is the design of the Swing's JTable. It uses a model,
>which provides information about the cells of the table, but doesn't
>hold any rendering data. When rendering time, one CellRenderer object
>is configured with one cell's data and context (position, selection,
>etc) a time, and is responsible for rendering it properly. This way,
>the table model doesn't have to hold rendering information (position,
>color, border, etc), only its contents.
>
>For handling large sets of data tuples, there is a pattern in "J2EE
>Core Patterns", called ValueListHandler. Its 1st Edition is published
>at Sun's site:
>
>http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
>
>and its 2nd Edition has been released recently (my copy will arrive
>soon), with updated and new patterns.
>
>regards
>Tetsuo
>
>
>Sanjiv Kapila wrote:
>
>>Can any one highlight me pros & cons of Flyweight vs Value Object
>>paatern. As per my understanding Flyweight calls for dividing the
>>result or their transfer across n/w in smaller bunched to avoid
>>overloading whereas value object clubs diff. request in one to save
>>multiple calls over network.
>>
>>Also I would like to know code snippet for making a flyweight pattern
>>i.e. segregating a resulset in multiple bunches. I know we have
>>fetchSize() that can define the no of records to fetch but how to
>>indicate that pointer for starting record. Also what will happen if
>>during this fetching some new records are inserted in the requested
>>table?
>>
>>Regards
>>Sanjiv
>>
>>====================================================================
>>Companion Site: http://www.corej2eepatterns.com
>>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>>List Archive:
>>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>>listserv@(protected)
>
>====================================================================
>Companion Site: http://www.corej2eepatterns.com
>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>List Archive:
>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

----
Cell Phone: (650) 224 0233 --- Web Site: http://www.riehle.org

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)


©2008 junlu.com - Jax Systems, LLC, U.S.A.