Class Constants - pros and cons
in [Java Help]
|
From: Roedy Green on 26 Jul 2010 13:18 On Sun, 25 Jul 2010 07:14:44 +0200, Magnus Warker <magnux(a)mailinator.com> wrote, quoted or indirectly quoted someone who said : > > public static int COL_WHITE = 1; > public static int COL_BLACK = 2; These are neatly done with enums. Then you can have accessor methods to get at associated properties such as Color. See http://mindprod.com/jgloss/enum.html for examples. -- Roedy Green Canadian Mind Products http://mindprod.com You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.
From: Tom Anderson on 26 Jul 2010 13:33 On Mon, 26 Jul 2010, Tom McGlynn wrote: > 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. I am 90% sure that is absolutely not how 'flyweight' is defined in the Gang of Four book, from which its use in the programming vernacular derives. If you want to use a different definition, then that's fine, but you are of course wrong. > So is there a better word than flyweights for the extension of a > singleton to a set with cardinality > 1? Multipleton. More seriously, enumeration. tom -- Remember Sammy Jankis.
From: Tom Anderson on 26 Jul 2010 13:33 On Mon, 26 Jul 2010, Lew wrote: > 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. Ah, i thought it was probably something like that. tom -- Remember Sammy Jankis.
From: Lew on 26 Jul 2010 13:37 Lew wrote: >> 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. > Andreas Leitgeb wrote: > About 2.4GB are not much? > (200 mill * (8bytes plain Object + 4bytes for some ref to each)) > No, it isn't. Around USD 75 worth of RAM. > 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. > With that much data to manage, I'd go with the straightforward object model and a database or the $75 worth of RAM chips. Or both. Complicated code is more expensive than memory. And what about when the model changes, and you want to track star age, brightness, color, classification, planets, name, temperature, galactic quadrant, ...? With parallel arrays the complexity and risk of bugs just goes up and up. With an object model, the overhead of maintaining that model becomes less and less significant, but the complexity holds roughly steady. Saving a single memory-stick's worth of RAM is a false economy. -- Lew
From: Andreas Leitgeb on 27 Jul 2010 06:55
Lew <lew(a)lewscanon.com> wrote: > Lew wrote: >>> 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. > Andreas Leitgeb wrote: >> About 2.4GB are not much? >> (200 mill * (8bytes plain Object + 4bytes for some ref to each)) > No, it isn't. Around USD 75 worth of RAM. Except, if the machine is already RAM-stuffed to its limits... Even if the machine wasn't yet fully RAM'ed, then buying more RAM *and* using the arrays-kludge(yes, that's it, afterall) would allow even larger galaxies to be simulated. >> 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. > With that much data to manage, I'd go with the straightforward object > model and a database or the $75 worth of RAM chips. Or both. On some deeper level, a relational DB seems to actually use the "separate arrays" approach, too. Otherwise I cannot explain the relatively low cost of adding another column to a table of 100 million entries already in it. > And what about when the model changes, and you want to track star age, > brightness, color, classification, planets, name, temperature, > galactic quadrant, ...? With parallel arrays the complexity and risk > of bugs just goes up and up. With an object model, the overhead of > maintaining that model becomes less and less significant, but the > complexity holds roughly steady. 100% agree to these points. It's like fixing something with duct-tape. The result looks not very good, but it may last for a particular use, that otherwise would have required a redesign from scratch and possibly costly further ressources. (changing object to separate arrays *may* still be less cost&effort than switching to some database) If, collisions and break-ups of stars were also simulated (thus a varying number of them), then, suddenly, duct-tape won't fix it anymore, anyway... |