CODEWITHSUNDEEP
javaconfigurationbooleanconfiguration-files
intel_chris
intel_chris

Reputation: 826

What are the patterns/idioms for introducing [boolean] configuration flags/parameters in a Java application?

I have a Java application (an interpreter written in antlr4 to be precise) with numerous options in the code I would like to be [power] user configurable. Something like a config.properties file. Most of them are Boolean flags, if set, do this, else do that.

Currently, I have one class per flag, and the classes are scattered through-out the code, mostly in the same package where the implementation needs it. And, you can say:

import  my.package.DoThis;

   if (DoThis.isSet()) {
       doThis();
   } else {
       doThat();
   }

where the code for DoThis is something like

package my.package;

public class DoThis {

  private static Boolean doThis = true; // the default
  public static Boolean isSet() { return doThis; }
  public static void set() { doThis = true; }
  public static void clear() { doThis = false; }
}

And, there is a centralized part of the code that main calls, that initializes these options.

public void setup() {
   DoThis.set();
   DoAnother.clear();
   if (cmd.option.debug()) { DoThird.set(); } else { DoThird.clear(): }
}

But, as I said, I'd like to clean the code up and use a configuration file that I can keep in the resources or a power user can override. A properties file or maybe a json file would seem like the right user interface.

However, properties read strings, do I check for yes/no, true/false? to set the flag. Or is there something better to do?

Should I also make all the options part of one class and perhaps store them in a map? What will make adding configuration options easiest?

Most importantly, I'd like to follow some form of Java best practices for doing so. I don't want to be that person who can write FORTRAN in any language. I want the code to look like what other Java programmers would naturally write. I'm pretty certain what I have now is not it.

Upvotes: 1

Views: 180

Answers (1)

Ciaran McHale
Ciaran McHale

Reputation: 2244

I am not aware of a universally-accepted "best" approach for this. My preference would be not to have a separate class per flag, but rather to rather to centralise all the flags within a single class called, say, Config. It's public API might be something like the following (assuming the flags are called x, y and z):

public class Config {
  private boolean x;
  private boolean y;
  private boolean z;
  void setX(boolean value) { x = value; }
  boolean getX() { return x; }
  void setY(boolean value) { y = value; }
  boolean getY() { return y; }
  void setZ(boolean value) { z = value; }
  boolean getZ() { return z; }
}

If you don't want to have to pass an instance of Config as a parameter to lots of different operations/constructors in your application, then you could create a singleton instance of Config.

I don't think my suggestion above would be too controversial among programmers. What is more likely to attract controversy is opinions about the "best" way to initialise the Config object. Some people might suggest that the Spring Framework should be used to inject values obtained from an XML file. Some other people might suggest that your setup() operation should read values from a configuration file in whatever happens to be your favourite syntax (properties, JSON, XML or whatever) and possibly allowing command-line options to override values specified in the configuration file

Upvotes: 1

Related Questions