创建多个全局常量的正确方法？

Question

I work on a (kind of old) application where there's a maze of huge global enums / classes that declare constant keys / classes that declare constant sets of key/values.

Many of these values are basically redundant... the same basic constant is declared in different enums under slightly different names, in each one of them it is associated with a different set of values.

Often times such a class refers to values in other similar huge classes, to create some hierarchy of constants... as you can see in the example below.

What are the right ways to define such constants? Should they be hard coded at all like now?

Example:

public class ParameterSet {

    //hundreds of similar declarations..........

    public static ParameterTypeAbstract BREADCRUMB1_BREADCRUMB2_BREADCRUMB3_BREADCRUMB4_452 = new ParameterTypeSet(
            KeywordType.PARAMETER_OF_SOME_TYPE_26659,
            ParameterGroupType.PARAMETER_OF_SOME_OTHER_TYPE_967347,
            ParameterScopeType.ACCOUNT_TYPE_557.ACCOUNT_SUB_TYPE_33791.getStringCode(), ParameterScopeImportantType.getStringCodes(),
            "Some description",
            true, true, true, null, null);

    public static ParameterTypeAbstract BREADCRUMB1_BREADCRUMB2_BREADCRUMB3_BREADCRUMB4_453 = new ParameterTypeSet(
            KeywordType.PARAMETER_OF_SOME_TYPE_90689,
            ParameterGroupType.PARAMETER_OF_SOME_OTHER_TYPE_867335,
            ParameterScopeType.ACCOUNT_TYPE_538.ACCOUNT_SUB_TYPE_48224.getStringCode(), ParameterScopeImportantType.getStringCodes(),
            "Some other description",
            true, true, true, null, null);

    //hundreds of similar declarations..........
}

Answer 1

Here are some strategies I have used in the past. It would have been easier to answer, if I knew what actual problem you are trying to solve and frankly, I can't really make much sense of BREADCRUMB1_BREADCRUMB2_BREADCRUMB3_BREADCRUMB4_452 . To give an illustrative answer, I will assume the following example: Suppose we want to do some graphics and use color palettes for that. We want several palettes (eg Tango , Gnome , etc) each with a finite set of named colors. Our requirements are:

• Provide a consistent interface to the nested structure of constants.
• Provide a statically type safe way to refer to a color in a palette.
• Provide a convenient (and preferably efficient) way to look up (at run-time) palettes and colors by name.
• Provide a convenient (and preferably efficient) way to enumerate (at run-time) all palettes and colors.
• Prefer external configuration sources.

We want to represent colors by instances of the immutable Color class that has a constructor that takes a packed RGB value as argument.

Nested Classes with Pubic Static Constants

public final class Palettes {

    public static final class Tango {

        public static final Color BUTTER_LIGHT = new Color(0xFCE94F);
        public static final Color BUTTER_MEDIUM = new Color(0xEDD400);
        public static final Color BUTTER_DARK = new Color(0xC4A000);
        public static final Color ORANGE_LIGHT = new Color(0xFCAF3E);
        public static final Color ORANGE_MEDIUM = new Color(0xF57900);
        // Many more Tango colors...

        private Tango() { throw new Error("cannot be instantiated"); }
    }

    public static final class Gnome {

        public static final Color BASIC_3D_HIGHLIGHT = new Color(0xEAE8E3);
        public static final Color BASIC_3D_DARK = new Color(0x807D74);
        public static final Color GREEN_HIGHLIGHT = new Color(0xC5D2C8);
        // Many more Gnome colors...

        private Gnome() { throw new Error("cannot be instantiated"); }
    }

    // Many more color palettes...

    private Palettes() { throw new Error("cannot be instantiated"); }
}

These classes are trivial and can easily be generated as part of the build process. Personally, I like keeping such data in XML files and using XSLT style-sheets to generate Java (or whatever) code from them. I have “disabled” the constructors of the classes and declared them final since a class with only static members should be neither instantiated nor subclassed.

Let's see how well this solution fits our requirements.

If we want to refer to a color in a palette and know which one we want at compile time, we can do it like this:

Color color1 = Palettes.Tango.ORANGE_LIGHT;

This gives us static type checking; if we accidentally refer to a non-existing color or palette or misspell a name, the compiler will tell us.

Color color2 = Palettes.Gonme.GREEN_HIGHLIGHT;  // compile-time error
Color color3 = Palettes.Gnome.GREEN_HIHGLIGHT;  // compile-time error

What if we get at run-time a palette and color name from a user and want to look it up? There is no convenient way for this. There can be no doubt that the following solution is a terrible one, even if the code can be easily generated from the same data source as the classes.

public Color selectColor(final String palette, final String color) {
    switch (palette) {
    case "Tango":
        switch (color) {
        case "Butter Light":       return Palettes.Tango.BUTTER_LIGHT;
        case "Butter Medium":      return Palettes.Tango.BUTTER_MEDIUM;
        case "Butter Dark":        return Palettes.Tango.BUTTER_DARK;
        case "Orange Light":       return Palettes.Tango.ORANGE_LIGHT;
        case "Orange Medium":      return Palettes.Tango.ORANGE_MEDIUM;
        // case ...
        default: throw new IllegalArgumentException(String.format(
            "There is no color '%s' in palette '%s'", color, palette));
        }
    case "Gnome":
        switch (color) {
        case "Basic 3D Highlight": return Palettes.Gnome.BASIC_3D_HIGHLIGHT;
        case "Basic 3D Dark":      return Palettes.Gnome.BASIC_3D_DARK;
        case "Green Highlight":    return Palettes.Gnome.GREEN_HIGHLIGHT;
        // case ...
        default: throw new IllegalArgumentException(String.format(
            "There is no color '%s' in palette '%s'", color, palette));
        }
    // case ...
    default:
        throw new IllegalArgumentException(String.format(
            "There is no palette '%s'", palette));
    }
}

An alternative would be to use reflection, which is probably better but still an indicator of a poor design choice.

The same goes for enumerating all palettes / colors.

Nested Dictionaries

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

final class GlobalConstants {

    public static final Map<String, Map<String, Color>> COLOR_PALETTES = GlobalConstants.makeColorPalettes();

    private static Map<String, Map<String, Color>> makeColorPalettes() {
        final Map<String, Map<String, Color>> colorPalettes = new HashMap<String, Map<String, Color>>();
        // These could be loaded at class load time from an external
        // configuration.
        {
            final Map<String, Color> palette = new HashMap<String, Color>();
            palette.put("Butter Light",       new Color(0xFCE94F));
            palette.put("Butter Medium",      new Color(0xFCE94F));
            palette.put("Butter Dark",        new Color(0xFCE94F));
            palette.put("Orange Light",       new Color(0xFCE94F));
            palette.put("Orange Medium",      new Color(0xFCE94F));
            // Many more Tango colors...
            colorPalettes.put("Tango", Collections.unmodifiableMap(palette));
        }
        {
            final Map<String, Color> palette = new HashMap<String, Color>();
            palette.put("Basic 3D Highlight", new Color(0xEAE8E3));
            palette.put("Basic 3D Dark",      new Color(0x807D74));
            palette.put("Green Highlight",    new Color(0xC5D2C8));
            // Many more Gnome colors...
            colorPalettes.put("Gnome", Collections.unmodifiableMap(palette));
        }
        // Many more color palettes...
        return Collections.unmodifiableMap(colorPalettes);
    }

    private GlobalConstants() { throw new Error("cannot be instantiated"); }
}

My choice of java.util.Map is more a placeholder than a suggestion. One should probably define a specialized ColorPalette class with a more descriptive name that provides the needed methods.

Once we have decided to put the constants into dictionaries that are assembled at run-time, we need no longer use code generation to hardcode our constants into Java source. We can still do that if we want (generating a file as the one shown) but we could equally well read the information from a property file, query a database or whatever.

This comes, of course, at the cost of lost static type checking. We can still conveniently refer to any color in any palette:

Color color1 = GlobalConstants.COLOR_PALETTES.get("Tango").get("Orange Light");

However, these will now be run-time errors:

Color color2 = GlobalConstants.COLOR_PALETTES.get("Gonme").get("Green Highlight");  // NullPointerException
Color color3 = GlobalConstants.COLOR_PALETTES.get("Gnome").get("Green Hihglight");  // color3 == null, surprise will come later

Looking up palettes and colors at run-time is now trivial since we do it effectively the same way as we do it for compile-time constants.

public Color selectColor(final String palette, final String color) {
    final Map<String, Color> thePalette;
    final Color theColor;
    thePalette = GlobalConstants.COLOR_PALETTES.get(palette);
    if (thePalette == null)
        throw new IllegalArgumentException(String.format(
            "There is no palette '%s'", palette));
    theColor = thePalette.get(color);
    if (theColor == null)
        throw new IllegalArgumentException(String.format(
            "There is no color '%s' in palette '%s'", color, palette));
    return theColor;
}

In addition, enumerating all palettes or all colors in a palette has become just a matter of a “for each” loop and will be very efficient.

Enum Classes

Finally, we'll have a look at Java's ever so powerful enum s.

enum TangoPalette {

    BUTTER_LIGHT(new Color(0xFCE94F)),
    BUTTER_MEDIUM(new Color(0xEDD400)),
    BUTTER_DARK(new Color(0xC4A000)),
    ORANGE_LIGHT(new Color(0xFCAF3E)),
    ORANGE_MEDIUM(new Color(0xF57900));
    // Many more Tango colors...

    private final Color color;

    TangoPalette(final Color color) {
        this.color = color;
    }

    public Color asColor() {
        return this.color;
    }
}

enum GnomePalette {

    BASIC_3D_HIGHLIGHT(new Color(0xEAE8E3)),
    BASIC_3D_DARK(new Color(0x807D74)),
    GREEN_HIGHLIGHT(new Color(0xC5D2C8));
    // Many more Gnome colors...

    private final Color color;

    GnomePalette(final Color color) {
        this.color = color;
    }

    public Color asColor() {
        return this.color;
    }
}

// Many more palettes...

This is again a candidate for code generation. What is probably most offending is that we have to repeat the logic for associating a Color with an enum in every palette. It doesn't look that bad in this example but will become worse once we want more data than a simple RBG value, perhaps with additional convenience methods.

Otherwise, this solution seems almost perfect, except for one major drawback: we cannot nest enum s. (At least, I'm not aware of a way to do this.) This means it is effectively a mix of the above two approaches.

Here is how we refer to constants at compile time:

Color color1 = TangoPalette.ORANGE_LIGHT.asColor();
Color color2 = GonmePalette.GREEN_HIGHLIGHT.asColor();  // compile-time error
Color color3 = GnomePalette.GREEN_HIHGLIGHT.asColor();  // compile-time error

This profits again from full static type checking. Having to write .asColor() is not nice but only a minor annoyance in my opinion.

The convenience of looking up colors at run-time is somewhere in between the above two approaches. We still need to write our own logic to select the palette but once we have it, we can use the valueOf method.

public Color selectColor(final String palette, final String color) {
    final String mangledColor = color.replace(' ', '_').toUpperCase();
    switch (palette) {
    case "Tango":
        return TangoPalette.valueOf(mangledColor).asColor();
    case "Gnome":
        return GnomePalette.valueOf(mangledColor).asColor();
    // case ...
    default:
        throw new IllegalArgumentException(String.format(
            "There is no palette '%s'", palette));
    }
}

Likewise, enumerating the colors from a given palette is simply a matter of using the values method.

If only we could make an additional enum with the names of all the palettes!

Conclusion

I like enum s so the last solution appeals most to me. Generally, I'd use the following rule of thumb:

• If you need recursive nesting, use the first approach with nested classes with public static constants.
• If it seems not implausible that values will be loaded from an external database in the future, consider using dictionaries.
• However, rather stay away from dictionaries if most values are already known at compile-time for the sake of static type checking.
• Use enum s especially if you only need one level of recursion.