Is storing configurations in memory more performance and maintenance efficient?

Question

My teammate has this class which contains a lot of Strings:

public class Config {

    /**
     * List of status
     */
    public static final String IN = "bla*";
    public static final String LUNCH = "bla*";
    public static final String OUT = "*bla";
    public static final String MEETING = "*bla";
    public static final String COFFEE = "*bla";

    public static final String ON_BREAK = "bla*";
    public static final String WORKING = "bla*";
    public static final String ON_MEETING = "bla*";
    public static final String IDLE = "bla*";


}

The above is just a sample. It also contains Strings of URLs and also Strings of sentences.

What would be the better way to store them?

What I've been initially doing as a refactoring process is I stored all the URLs in an application.properties file. Then I access them via Spring's @ConfigurationProperties. (Some URLs have tokens)

There's also a list of status as you can see above which are made up of an average of 2-10 letters. I've decided to create a Status enum containing these values.

Am I doing the right thing? Or should I just store all of it inside a json/csv?

Though I'd mainly want to know about where to store URLs. We're using around 7-10 URLs. (It's said to be the microservices we're calling, i don't really know about that as I don't have much experience in programming yet.)

Note: I'm not talking about which code will be better, rather I want to know if one way is more efficient than the other. Yeah, it could be based on personal taste. But performance results and future maintenance can say otherwise.

Possible duplicate of How would you know if you've written readable and easily maintainable code? — gnat, Nov 20 '18 at 06:42
Your peer tells you after reviewing the code. We don't have code review. GASP Yeah I know. There's only two of us, I just transferred here, and apparently this is the situation. — Rigo Sarmiento, Nov 20 '18 at 06:45
There are dozens of ways to store such a simple configuration, and none of them is really superior to any other. It is mainly a matter of taste, personal preference and what you do in similar applications of yours (that is why I am voting to close this question as "primarily opinion based"). — Doc Brown, Nov 20 '18 at 06:50

score 4 · Accepted Answer · answered Nov 20 '18 at 09:12

I'm not talking about which code will be better, rather I want to know if one way is more efficient than the other.

Then you are talking about the wrong thing.

The performance of this is not going to matter, ever, in any way.

That is, unless you do something stupid, like store it in a file or database and read it from there every single time you need the configuration options. That would be bad.

If you don't mess it up, the configuration will be read once from wherever it's stored, and then kept in memory.

Yeah, it could be based on personal taste. But performance results and future maintenance can say otherwise.

Maintenance is about what code would be better, and that really matters.

And what is better depends on how those Strings will be used and how often they will need to change:

For URLs of services, it's a very good idea to keep them in a separate properties file(or JSON, YML, doesn't really matter that much though having comments is good), because then they can be changed without rebuilding the application, even by someone with no coding experience.
For Strings that will show up on the UI, a separate file is also good because that makes it way easier to do translations, spell checking, consistency checking, or similar things.
A fixed list of statuses should definitely be an enum, for type safety and to make clear what is and is not a possible status.
Strings that are really only used inside the code and will likely change only when there are code changes should NOT be put into a properties file - such "soft coding" will only create maintenance problems.

score 1 · Answer 2 · answered Nov 20 '18 at 07:02

Use a flatfile whenever you need to send data of fixed size and a lot of it. If there are a few fields which vary, you could consider adding spaces to fill in the rest, but at the end of the day, the flatfile must be of fixed length.

However maybe you're dealing with descriptions as well. Descriptions not only vary, but you have no guarantees on the maximum length of the description in many cases. In this case, and again, assuming you have many many lines of this, you should consider using a csv file, as it lets you define field barriers. Just don't make the mistake of assuming a description cannot contain the characters being used as the barriers used in the csv. Pick a character that isn't likely going to be used, and replace that character in the fields you use in the csv to avoid the painstaking task of parsing it by hand later.

Properties files are, in my humble opinion, an excellent way to save values when you have key and values. Though unlike the flatfile and csv, you likely wouldn't be saving potentially many lines. Use properties files when you're saving configurations, as it seems to be in your case. This works just fine with URLs. In a properties file, the first "=" character is the one dividing the key from the value (in fact if you want to include a "=" character as part of the key, you must escape it). This to say that even if your URL contains an equals sign, you're not going to run into any problems.

To structure properties, you might consider adding a prefix first, such as:

[email protected]
config.password=iheartturkey

You can further nest properties by adding even more prefixes to better organize.

A trick I learned is to use \ character at the end of the line for multi-line properties. I've found this to be infinitely useful for saving SQL queries used throughout my program, as it allows me to change it in case of a problem in production, and it looks a lot cleaner than hardcoding a query in my code. Just be sure that the \ character is the last character on the line or else it gets interpreted as a simple \ character and your next line is interpreted not as the continuation but as its own key/value line.

If structure is crucial, you may consider using a format more appropriate for data structuring. For this, YAML and JSON are both excellent options. If you're programming in Java, the default tends to be using properties files, but don't feel obliged to use them.

With regards to using enums to represent data, that is an excellent idea if you expect a preset list of possible values. If you hit data that you don't expect, it fails, and that's a good thing believe it or not! It allows you to guarantee right at the start that your data is what you expect it to be.

Good luck!

score 0 · Answer 3 · answered Nov 20 '18 at 08:32

My experience is telling me that URIs for services/apis should be in a config file, which allows for build configuration transformation because dev won't be talking to the same instances as production right?

You can have properties on your class to make them available if that is required, but the raw values would be in the config.

For the large number of "status" type values... "magic strings" are considered poor practice but in the real world often still exist for the purposes of legacy integration reasons. It would be best to have maintained code be not dependent on magic strings to get away from typo risks. Might it be better to have an Enum of the possible values, but also a static Dictionary or a lookup table to cross reference when required for that legacy/display reason? (Exact solution would be dependent on your context)

Is storing configurations in memory more performance and maintenance efficient?

3 Answers3