In prior releases, the standard way to represent an enumerated type was the int Enum pattern: // int Enum Pattern - has severe problems! public static final int SEASON_WINTER = 0; public static final int SEASON_SPRING = 1; public static final int SEASON_SUMMER = 2; public static final int SEASON_FALL = 3;
This pattern has many problems, such as: Not typesafe - Since a season is just an int you can pass in any other int value where a season is required, or add two seasons together (which makes no sense). No namespace - You must prefix constants of an int enum with a string (in this case SEASON_) to avoid collisions with other int enum types. Brittleness - Because int enums are compile-time constants, they are compiled into clients that use them. If a new constant is added between two existing constants or the order is changed, clients must be recompiled. If they are not, they will still run, but their behavior will be undefined. Printed values are uninformative - Because they are just ints, if you print one out all you get is a number, which tells you nothing about what it represents, or even what type it is.
[ March 04, 2005: Message edited by: Carol Enderlin ]
Well, one you could easily type wrong and your compiler won't help you with it (if you had one ) so you would only use the String version if that's all you had and you wanted to get the constant (perhpas based on user selection on a web page?).
In prior releases, the standard way to represent an enumerated type was the int Enum pattern
In prior releases, the common, but very ugly way to represent an enumerated type, was using int or some equivalent form. The correct way was to implement the Type-safe Enumeration design pattern, which is all a 1.5 enum is in bytecode (loosely speaking). Unfortunately, this simple concept didn't propagate too far, and atrocities occurred.
Tony Morris Java Q&A (FAQ, Trivia)
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop