Re: Collection, enum or something else?
Todd wrote:
How would you handle a memory intensive application wherein an
intermediate object could be have a significant impact on memory?
I am coming back to wondering whether an interface provides the
proper mechanism for reducing unnecessary objects.
Well, here you blow right past anything we could do with a simple
example. If you have some concerns you should try to be explicit,
because it becomes darn hard to guess the right way to optimize this.
(Not that I'm an expert or anything.)
Profiling is the right way to optimize, but dealing with lots of data is
best done at a high level, by design, so you *can* optimize. And
without some particulars it's hard for us to comment on any architecture
that someone might propose.
One thing that does occur to me is immutable objects. If you make the
fields of ShrupProperties below final, you and the compiler both can
make a lot of optimizations on the object itself.
But that's a pretty micro optimization, not the kind of architectural
decision that you need.
This eliminates the need for the intermediate object
shown in the original post. This is likely still not
I don't think eliminating intermediate objects should be your goal.
Sounds dubious at best, if not a known bad practice. I'd have to see
more of your design (how many shrubs are we talking about here?) but
"substitute an enum for a Map" just seems like a very controversial
attempt at optimization, regardless of the design.