Attribute fields and attribute value map
I have a class (java) with about 10 attributes, many of which potentially remain uninitialized and not available during the lifetime of the object.
So I am considering using Map<String,Object>
the name-attribute-> value-attribute as a map instead of multiple fields to save resources.
Now I'm wondering if there are any formal or informal rules on when and how to tackle one of the described possibilities. How many attributes should a class have before I should consider using such a map? Should I be using it at all?
Thanks in advance for your advice and opinions.
source to share
So you are doing this to save memory, which I am assuming, because clearly you are not saving CPU resources by accessing the map instead of the field. So let's see how well it turns out: (assuming a 64-bit JVM without compressed oops - this is unrealistic, but shouldn't change the results too much, you can easily compute it yourself)
Basically a field in java will never take more than 8 bytes (the correct word size for links). So this means that for your class with 10 fields, assuming all unused, the best we can keep is 8 * 10 bytes = 80 bytes.
Now you want to replace this with one HashMap, which means we already used 8 extra bytes for that. Also the HashMap is always initialized, so we get an overhead: 2 words header + reference + 3 ints + float + 1 array (2 words overhead, 4 bytes, 16 references by default) that take up 182 bytes
memory.
May I congratulate you on saving the colossal -110 bytes
!
PS: I think the smallest possible default for the hashset support array is 2, so you can use that in and out about even. But once you store the objects in the collection, you get additional overhead from the Wrapper objects used by the class. So this is a really bad idea.
source to share
It's not about how many different attributes you have about how they are used and what is needed. A Map
will allow more flexibility to have no attributes, or have different attributes for different instances, or add attributes later (adding things in Map
). But if the attributes are of different types String, Integer, Doubles
, etc., this will require creating a Map
type Object
and emitting all values when using them (a lot more work for you).
source to share
I don't think the map is a good idea.
-
from an OO perspective, fields are properties of a type and its subtype. think about inheritance and polymorphism, how can you make a map to achieve these OO characters?
-
even when it comes to code style, it doesn't make your codes cleaner. How do you handle type casting? Exception Handling? these codes would be much more than field declaration and getter / setters (if you have any)
source to share
I like the idea of a map for attributes that are truly optional and "irrelevant". Otherwise, you need a whole bunch of subclasses and / or you always need to check for null in your receivers.
In terms of input, I often write code passing a default value as the second argument and using that to determine the return type. eg.
int getValue(String key, int defaultValue);
double getValue(String key, double defaultValue);
String getValue(String key, String defaultValue);
The caller, not the Card, must know the type. YMMV, do you like this style ...
However, for attributes that are "essential", I prefer real fields.
source to share