Re: Class Constants - pros and cons
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-85460952-1280402421=:30764
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Tue, 27 Jul 2010, Tom McGlynn wrote:
On Jul 26, 1:33?pm, Tom Anderson <t...@urchin.earth.li> wrote:
On Mon, 26 Jul 2010, Tom McGlynn wrote:
On Jul 26, 8:01 am, Tom Anderson <t...@urchin.earth.li> wrote:
But Joshua was talking about using instances of Color, where those
instances are singletons (well, flyweights is probably the right term
when there are several of them)
I don't think flyweights is the right word. ?For me flyweights are
classes where part of the state is externalized for some purpose. This
is orthogonal to the concept of singletons. E.g., suppose I were
running a simulation of galaxy mergers of two 100-million-star
galaxies. ?Stars differ only in position, velocity and mass. ?Rather
than creating 200 million Star objects I might create a combination
flyweight/singleton Star where each method call includes an index that
is used to find the mutable state in a few external arrays.
I am 90% sure that is absolutely not how 'flyweight' is defined in the
Gang of Four book
Here's a bit of what the GOF has to say about flyweights. (Page 196
in my version)....
"A flyweight is a shared object that can be used in multiple contexts
simultaneously. The flyweight acts as an independent object in each
context--it's indistinguishable from an instance of the object that's
not shared.... The key concept here is the distinction between intrinsic
and extrinsic state. Intrinsic state is stored in the flyweight. It
consists of information that's independent of the flyweight's context,
thereby making it shareable. Extrinsic state depends on and varies with
the flyweights context and therefore can't be shared. Client objects
are responsible for passing extrinsic state to the flyweight when it
needs it."
That's reasonably close to what I had in mind.
Yes, point taken. I'm still not happy with your usage, though.
IIRC, the example in GoF is of a Character class in a word processor. So,
a block of text is a sequence of Character objects. Each has properties
like width, height, vowelness, etc and methods like paintOnScreen. But
because every lowercase q behaves much the same as every other lowercase
q, rather than having a separate instance for every letter in the text, we
have one for every distinct letter.
The extrinsic state in this example is the position in the text, the
typeface, the style applied to the paragraph, etc. Certainly, things that
are not stored in the Character. But also not things that intrinsically
belong in the Character anyway; rather, things inherited from enclosing
objects.
Whereas in your case, the array offset *is* something intrinsic to the
Star. If it had been something else, say the coordinates of the centre of
mass of the local cluster, then i'd agree that that was Flyweightish. But
i'm not so sure about the array index.
It might well be that i have an over-narrow idea of what a Flyweight is.
Getting back to my original concern, I don't think enumeration is a good
word for the concept either. Enumerations are often used for an
implementation of the basis set -- favored in Java by special syntax.
However the word enumeration strongly suggests a list. In general the
set of special values may have a non-list relationship (e.g., they could
form a hierarchy). I like the phrase 'basis set' I used above but that
suggests that other elements can be generated by combining the elements
of the basis so it's not really appropriate either.
I can't think of a good word for this. Do we need one? What are some
examples of this pattern in the wild?
tom
--
If you're going to print crazy, ridiculous things, you might as well
make them extra crazy. -- Mark Rein
--232016332-85460952-1280402421=:30764--