I previously posted about how to automatically format an enum value by overriding the enum's toString() method. The code works, but it doesn't scale very well and it's not as robust as it could be, so I've pulled it out into it's own method, and added a "case exception list" feature, so it can be called from any enum, and allows for more flexibility:
public class EnumUtils {which is called from the enum like this, for example:
public static String displayFormat(String enumName, String... caseExceptions) {
String[] splitNames = enumName.split("_");
String caseExceptionName = "";
Boolean caseException = false;
for(String name : caseExceptions) {
String parsedName = name.replace(" ", "_");
if(enumName.equalsIgnoreCase(parsedName)) {
caseExceptionName = parsedName.replace("_", " ");
caseException = true;
}
}
StringBuffer fixedName = new StringBuffer();
if(caseException) {
fixedName.append(caseExceptionName);
} else {
for(int i = 0; i < splitNames.length; i++) {
String firstLetter = splitNames[i].substring(0, 1).toUpperCase(),
restOfWord = splitNames[i].substring(1).toLowerCase(),
spacer = i == splitNames.length ? "" : " ";
fixedName.append(firstLetter).append(restOfWord).append(spacer);
}
}
return fixedName.toString();
}
}
@OverrideThe method takes in the name of the enum value, as usual, but also allows the developer to specify a variable-length exception list, thanks to Java's "varargs" feature, which lets you accept an array of any basic type as the last argument. All you need to do in the method is specify the type along with ellipses (...), and it takes care of the rest for you. The code allows the developer to specify the enum value with a space between words, or with "_"'s. BTW, it also works fine with no exceptions:
public String toString(){
return EnumUtils.displayFormat(name(), "NT Servers", "SQL Server");
}
return EnumUtils.displayFormat(name());If you've seen my original code in the post below, you'll also noticed that I've changed StringBuilder to StringBuffer, and changed the String.concat()s to StringBuffer.append()s. StringBuilder is actually just meant for single-threaded operations, so while it's probably safe to use it here, it could potentially wreak havoc. The append()s are for miniscule performance gains (though I haven't run tickcount tests yet to actually confirm that this method is faster). I've also defined the new strings in the second for loop with commas between them, instead of re-typing "String" three times. I heavily doubt there's a performance gain here, as I assume the compiler sees both the same, but it's slightly faster to type :-)
BTW, I'm now using the Blogger Syntax Highlighter to display formatted code, as it looks a bit nicer, and has native support for Java.