In java <1.5, constants would be implemented like this
public class MyClass {
public static int VERTICAL = 0;
public static int HORIZONTAL = 1;
private int orientation;
public MyClass(int orientation) {
this.orientation = orientation;
}
...
and you would use it like this:
MyClass myClass = new MyClass(MyClass.VERTICAL);
Now, in 1.5 obviously you should be using enums:
public class MyClass {
public static enum Orientation {
VERTICAL, HORIZONTAL;
}
private Orientation orientation;
public MyClass(Orientation orientation) {
this.orientation = orientation;
}
...
and now you would use it like this:
MyClass myClass = new MyClass(MyClass.Orientation.VERTICAL);
Which I find slightly ugly. Now I could easily add a couple of static variables:
public class MyClass {
public static Orientation VERTICAL = Orientation.VERTICAL;
public static Orientation HORIZONTAL = Orientation.HORIZONTAL;
public static enum Orientation {
VERTICAL, HORIZONTAL;
}
private Orientation orientation;
public MyClass(Orientation orientation) {
this.orientation = orientation;
}
...
And now I can do this again:
MyClass myClass = new MyClass(MyClass.VERTICAL);
With all the type-safe goodness of enums.
Is this good style, bad style or neither. Can you think of a better solution?
Update
Vilx- was the first one to highlight what I feel I was missing - that the enum should be a first-class citizen. In java this means it gets its own file in the package - we don't have namespaces. I had thought this would be a bit heavyweight, but having actually done it, it definitely feels right.
Yuval's answer is fine, but it didn't really emphasise the non-nested enum. Also, as for 1.4 - there are plenty of places in the JDK that use integers, and I was really looking for a way to evolve that sort of code.
You should use enum types any time you need to represent a fixed set of constants. That includes natural enum types such as the planets in our solar system and data sets where you know all possible values at compile time—for example, the choices on a menu, command line flags, and so on.
If you ever need to change the value of a String constant, it is a one-line change. With an enum it can get more complicated due to having separate values for name and toString, and those values possibly being used in conditional logic.
Enums provide readability and flexibility over a class with constants. Few other advantages that I can think of enum types. They is always one instance of a particular enum class (hence the concept of using enums as singleton arrives). Another advantage is you can use enums as a type in switch-case statement.
Unlike C and C++ Enum in Java are much powerful and they are not an integer constant, Instead, Enum is a Type like class or interface which provides compile-time type safety.
You complicated it too much. Let's bring it all together.
Post Java 1.5 you should use the Java Enum class:
public enum Color
{
BLACK, WHITE;
}
Pre Java 1.5 you should use the type-safe Enum pattern:
public class Color
{
public static Color WHITE = new Color("white");
public static Color BLACK = new Color("black");
private String color;
private Color(String s)
{
color = s;
}
}
In both ways you call it like so:
drawBackground(Color.WHITE);
Specifically, regarding your question. It's a matter of code style, but I think the preferred way is to keep enums in their separate classes. Especially once they start to get their own methods like getName()
, getId()
, etc... Think of it as the same dilemma as regular class vs. anonymous class, once the class starts to get cluttered, it's time to move it out to its own file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With