Class Constants - pros and cons
in [Java Help]
|
From: Tom Anderson on 26 Jul 2010 08:01 On Sun, 25 Jul 2010, Lew wrote: > Magnus Warker wrote: >>>>> It's the readibility of the code. >>>>> >>>>> With constant classes I can write something like this: >>>>> >>>>> public void setColor (Color color) >>>>> { >>>>> if (color == Color.WHITE) > > Lew wrote: >>> No. That would be a bug. You'd write >>> 'if ( color.equals( Color.WHITE ) )'. > > Joshua Cranmer wrote: >> To be pedantic, it would not be a bug if the Color class were written in >> a certain way, i.e., there is no other Color instances other than those >> in Color's static instance variables. > > You are wrong, this once. (In your case, an extremely rare occurrence.) > > It's impossible to enforce that for all clients 'color' is assigned the > exact instance, therefore that == will work if the static variables are > Strings. It's all too easy to accidentally push in a different constant > String from some other class, as outlined in my other response, or by > other means to create a different instance of a String that you intend > even with the correct value. So yes, to be pedantic, using == would be > a bug waiting to happen, as would using String constants when enum > constants are so much safer (and guaranteed to work with == ). I won't argue with you about Strings. 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), exposed in static final fields on Color, and the class is written in a certain way, which i take to mean having a private constructor, not creating any instances other than those in the statics, and implementing readResolve. In that case, how can there be pairs of instances for which .equals is true and == isn't? Colour doesn't make such instances, no other class can make such instances directly, serialization won't, and sun.misc.Unsafe is a foul. Indeed, this is exactly what enums do, so why do you think classes can't? tom -- If goods don't cross borders, troops will. -- Fr
From: Lew on 26 Jul 2010 08:58 Tom Anderson wrote: > I won't argue with you about Strings. > > 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), exposed in static final fields on > Color, and the class is written in a certain way, which i take to mean > having a private constructor, not creating any instances other than > those in the statics, and implementing readResolve. In that case, how > can there be pairs of instances for which .equals is true and == isn't? > Colour doesn't make such instances, no other class can make such > instances directly, serialization won't, and sun.misc.Unsafe is a foul. > > Indeed, this is exactly what enums do, so why do you think classes can't? We're talking apples and oranges here. I made a mistake and it's my fault. I was focused on String constants and should not have used 'Color' instances as an example, but 'Foo'. In my mind I had conflated the examples and was imagining a fictitious 'Color' class with Strings not 'Color' instances, and that was where I went wrong. You and Joshua are, of course, correct. -- Lew
From: Tom McGlynn on 26 Jul 2010 09:37 On Jul 26, 8:01 am, Tom Anderson <t...(a)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), exposed in static final fields on Color, and .... While I agree with Tom's main point here,I am dubious about his suggestion for what the static instances should be called in a class that only creates a unique closed set of such instances. 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. At least in some versions of Java this could be a very useful optimization since we only need to create of order 10 objects rather than 10^8. So is there a better word than flyweights for the extension of a singleton to a set with cardinality > 1? Tom McGlynn
From: Lew on 26 Jul 2010 11:31 Tom McGlynn wrote: > 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. At least in some versions of Java this > could be a very useful optimization since we only need to create > of order 10 objects rather than 10^8. Except that that "mutable state in a few external arrays" still has to maintain state for order 10^8 objects, coordinating position, velocity (relative to ...?) and mass. So you really aren't reducing very much, except simplicity in the programming model and protection against error. -- Lew
From: Andreas Leitgeb on 26 Jul 2010 12:29
Lew <lew(a)lewscanon.com> wrote: > Tom McGlynn wrote: >> 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. At least in some versions of Java this >> could be a very useful optimization since we only need to create >> of order 10 objects rather than 10^8. > Except that that "mutable state in a few external arrays" still has to > maintain state for order 10^8 objects, coordinating position, velocity > (relative to ...?) and mass. So you really aren't reducing very much, > except simplicity in the programming model and protection against > error. About 2.4GB are not much? (200 mill * (8bytes plain Object + 4bytes for some ref to each)) Of course that needs to be taken in relation to the perhaps 8GB of RAM still needed for the 5 doubles per star: about 33% of payload would be "packaging" costs with a separate instance for each star! I for myself might choose the perhaps less cpu-efficient (due to all the repeated indexing and for the defied locality) and also less simple programming model, if it allowed me to solve larger problems with the available RAM. PS: Without further tricks, each single simulation-step would probably take much too long, anyway, if for each star its interaction with each other star needs to be calculated... But then it was only thought- experiment, in the first place ("... suppose I were running ...") |