在从文件读取更好的数据行之前，枚举有多复杂（例如.csv）？

Question

I have created part of a platformer game where I have an actor class, representing instances of objects and characters, and a type enum which denotes what data each actor will have (such as speed, attack, defence, etc). Specifying all the data of each type seems somewhat tedious with hardcoded enum definitions. Eg

PLANE("Plane", 10, 10, 2, 0),
MISSILE("Missile", 1, 0, 0, 4);

Would it be best to specify data in a file and read it instead?

Answer 1

My answer to that question would now be: Take a DSL for it, for instance using Kotlin (similar things are possible in Groovy).

Without going into any detail, the following can be valid Kotlin (actually working code copied from a production system):

buildTreats {
    category(BEVERAGE) {
        treat(id = 2, key = "bonusfood.treat.appleJuice") {
            47.kcal
            0.5 of GLASS
        }
    …
    }
    …
}

The advantage is that you have full code completion and compile-time checks that you just cannot have with a CSV file.

Answer 2

Some thoughts here:

• instead of giving a "human readable" name string to your enum, you could as well @Override the toString() method to automatically return Plane for PLANE (easy - just lowercase everything except first letter)
• such code breaks your ability to add more features later on

There is the old Open/Closed principle . Basically it is saying: your code needs should be open in those areas where change is most likely to happen.

I am pretty sure: today you need 4 values, like 10, 10, 2, 0 for a Plane, as above. But in a few days, you might want to have more attributes. Then you have to turn to all your enum constants and update them.

In that sense, it might be better to give up a bit of compile time safety here; and use a Map instead. Map key could be an enum (just listing the different potential properties some player/item/... has). Map key would be the specific value for that strength.

If you would want to go down that route, you could then specify a type for each enum constant. So that you know that a map value for STRENGTH for example would be a Integer object, or something alike.

In other words: you might turn into the dark realms of reflection here.

Answer 3

The beauty of enum is that they are fixed in code and will not change. This provides huge benefits when coding, type checking and you can make Map s and Set of them and you can iterate across them and even switch-case with them (although that is less common now they can have their own functionality). You can even save them in a database so long as you use their names and the data still maps back correctly even when the enum list changes.

As such, I would not abandon them , I would probably add a new one called perhaps "OTHERS" which can somehow provide any new ones that are experimental etc.

If your core issue is with the tediousness of maintaining the parameters then by all means read that data in from configuration using a static initialiser.