0

So I was searching about storing data in one class, and found this. However, that's not what I'm looking for. What I wanted to know about this was whether it's bad practice, can cause performance issues in an application, or if there's another way to do it, etc... (and I'm not doing this on an Android).

Let's say I have a class that stores a HashMap<Enum, Object> and is initialized when I create the class in main.

public Main() {
    // Creates the HashMap, initialized in the constructor 'MemoryContainer'
    MemoryContainer m = new MemoryContainer();
    m.getTestHash().put(SomeEnum.TEST, "Test"); // Using created HashMap
}

Other than casting the value every time I use it, would this cause major issues? If so, is there an alternative?

DevRj
  • 448
  • 8
  • 19
FlashDaggerX
  • 89
  • 10

3 Answers3

0

I would not look too much at performance issues (of course, I do not know what else your application does or wants to do and how it achieves it).

What you should look at first is Mutability - in your example, nothing would stop me from changing the configuration at Runtime by calling m.getTestHash().put(SomeEnum.TEST, "NotATestAnymore") - this would immediately change the behaviour for every other use of that specific setting.

I am also not sure why you would not just use a configuration class that would directly provide (typed) getters and, if you know all configuration settings at the launch of the app, one constructor containing all the settings.

Do you plan to read the configuration from an outside source (e.g. file)?

user765778
  • 31
  • 3
  • What I plan to do with it is use it as a Storage for settings. I wanted it to be flexible so I could change it at any point in time in my code. I always call this class `MemoryContainer` in my projects, and I always access said memory from the entry point of the application (main) – FlashDaggerX Jul 28 '17 at 14:28
  • If you actually want to change these settings at runtime, you will need a modifiable class, but I still advise against using a Map - instead have a dedicated class with setters and getters that are referencing the needed type. – user765778 Aug 14 '17 at 08:23
0

NO,

It won't cause major issues.

Also, it is a good practice to keep those variables (HashMap in your case) in a different class away from your main class (which contains your app logic).

Android Admirer
  • 2,310
  • 2
  • 17
  • 38
0

There's nothing wrong with storing static values in a class, however this is not a good practice.

To store the constants you should create an interface as every field in an interface is already a constant (public static final).

A better approach will be to store these values in properties files, and load them as needed. A properties file can be stored externally and a person who isn't aware of your source code would be able to modify this properties file if needed. For example you can store database connection details in properties files and if server support admin determines that database instance is down, he/she can edit the properties file to point the application to a new one.

Finally for most flexibility you shouldn't store the configuration inside application at all. It can be stored in a database like MySql or in a fast data structure storage like Redis. This will allow multiple instances of your application to share the configuration data and it will also allow you to modify configuration on the fly by modifying them in the database.

Sometimes a Git repository is also used to store this kind of data (like in case of microservices). Git repository in addition to being shared among all the instances, also maintains the history of modifications.

11thdimension
  • 10,333
  • 4
  • 33
  • 71