Better way to store a massive amount of variables

Newbie & Debugging Questions
#21

Tons of frameworks use beans. Saying we don’t use beans much anymore doesn’t make any sense. They’re used all over the place.

Opiop said this was a data class for a web application. I’d be willing to bet that it requires a bean.

And more than that, you have to think about readability and maintainability. A simple bean class with fields, getters, and setters is instantly understandable, and it’s hard to mess up. A custom implementation with a Map is much more needlessly complicated. Other people working on the code are going to need to understand how your map works (Is it keyed off String values? If so what happens if I add a String key to it that wasn’t originally in the class? What are the default values?), versus simply looking at what getters and setters are available. The possibility of having somebody screw the code up is increased with a Map, and people will look at you funny and ask what specific technical reason you had for switching the implementation. “I didn’t like the way the code looked” isn’t really a valid reason.

There are valid reasons to use a Map, but I think it’s incorrect to say “nobody uses beans, just use a map”. I would argue the opposite of you: unless there’s a real reason to NOT have it as a bean, you should just use a bean.

#22

For the sake of the IDE’s auto-complete feature, I would steer clear of Maps and instead use the dot-operator or getters and setters.
Reminds me of how much I hate trying to remember the String property key “file.separator” or “os.name” in java.lang.System.getProperty():
https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperty-java.lang.String-

I wonder why the JDK designers used this map-style property mechanism for the System class? Perhaps it’s a legacy thing from JDK1.0.

Maps introduce another level of indirection for little gain, in my opinion.

Someone here once said that using getters and setters in public API’s for wider distribution and public variables (SomeClass.varName) in your own personal projects was the way to go.

#23

that plus what Cas said. split classes with too many fields into nested ones - keep it readable and organised.

#24

If you have a lot of properties and its just properties it is not really a bean in the first place. Your not suppose to have 100s of fields. As cas says, your doing it wrong in that case. A good example is that lookup in a map will generally be as fast as reflection used on a bean, and often faster. And it represents what it really is better. A set of properties, rather than a class that should encapsulate some sort of concern.

Even a pure data bean typically groups a small set of fields that reflect a single “concern” or aspect or whatever you kids call it these days. Large monolithic classes with 100s of fields is just bad no matter how you slice it.

Oh in many EE stuff they have moved from beans to POJO these days. Annotations can take care of most DB mapping more or less. At least the last few places i worked.

#25

Let’s remember that “do nothing” accessor methods result in the exact same code as using the accessor operator. (OK technically it isn’t an operator). So the performance difference is none (assuming HotSpot, IBM’s JVM and probably ARC … and assuming you haven’t explicit disable the optimization via command line argument or equivalent).

Another thing about maps is the ABI doesn’t change when you add new properties.