On 21.10.2011 23:19, A. W. Dunstan wrote:
I'm writing a GUI that's a wrapper around some Fortran code. In one of
the Fortran routines I pass in an integer that tells the Fortran code
what kind
of 'cloud model' to use (it's a big physics simulation). For example:
value meaning
----- ---------
0 no clouds
1 cumulus
2 altostratus
18 cirrus
etc. The Fortran is 3'rd party software so changing values& their
meanings isn't an option.
I'd use a plain enum but the values passed in aren't continuous (as above
-
it skips from 2 up to 18), nor do they necessarily start at zero. So I
wrote my own enum where I could associate a name, a value and a
description:
public enum CloudModel {
None(0, "No clouds"),
Cumulus(1, "Cumulus"),
AltoStratus(2, "Altostratus"),
Cirrus(18, "Cirrus");
CloudModel(int value, String description)
{
m_value = value;
m_desc = description;
}
public int getValue() { return m_value; }
public String toString() { return "" + m_value + ": " + m_desc; }
private int m_value;
private String m_desc;
}
This works but I'm now up to six different enums (Cloud coverage,
atmospheric model, haze, surface reflectance, etc), and they all look
nearly
the same. Each one has identical getValue() and toString() methods,
m_value
and m_desc. And the constructor varies only in it's name - the body of
each
constructor is the same. Creating a new enum is easy - cut& paste,
change the name of the constructor, type in the values and I'm done.
This works too, but code reuse by cut-and-paste worries me. I'd like to
extract the methods& member variables into a base class of some sort and
extend that, providing the enumeration values in each derived enum. BUT
- I
can't extend from an enum. If I could put the common parts in a separate
class and mix that in (as in Ruby) that'd be great, but Java isn't Ruby.
My code will be called from Matlab (which can access Java objects&
methods
directly) so I'd like to keep it as an enum. And enums are easy to load
into a JComboBox, which makes that part of the GUI code cleaner.
I'm ok with leaving it the way it is, but does anyone know of a better
approach? Preferably one that's not so complex that it's worse than my
current state of affairs?
I don't think it gets any better. Even if you go away from enums and
create an abstract base class etc. you'll have to do the typing for the
values plus you need to take care of serialization etc. (only once in
the base class though) and you still need to define a constructor - even
if it's then only
private Foo(int value, String description) {
super(value, description);
}
But I would probably choose different names instead of calling them all
getValue(). After all, these are all different values or having a
different meaning in different enums. If you do that the common base
class wouldn't help you much any more. I think I'd stick with enums.
Some more remarks: I'd make fields final because that's what they should
be for an enum. Since you are not accessing m_desc from anywhere
outside you could make your code more efficient by storing the value
returned by toString() in a String member. Since you have those enums
in the GUI I assume that toString() is invoked fairly often but the same
String will be created over and over again so you could as well store
that.
Kind regards
robert
Both good ideas. Thanks!
OptiMetrics, Inc.
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
- C. A. R. Hoare