Re: Initializing a Map in an Interface?
On 3/16/2010 4:17 PM, Rhino wrote:
On Mar 16, 2:12 pm, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
On 3/16/2010 2:39 PM, Rhino wrote:
[...]
I remember being told that an Interface containing only constants was
a good (or at least reasonable) idea on this same newsgroup some years
ago.... Then again, as you say, the Java Community has gradually
evolved better ways of doing things. I have been away from Java for
several years and things have obviously evolved in my absence. I need
to play some catchup now.
You must have been away quite a while. Bloch recommended
against constant-only interfaces in the first edition of "Effective
Java," copyright 2001.
What is a better way to keep persistent data
if an Interface is not the best way?
"Persistent data" could mean a lot of different things, and
I don't know which you intend.
I have a variety of interfaces containing only constants for various
programs. For instance, I use them to store the base names of the
resource bundles I use for a given program and for the name of the log
file that the program should be generating. It sounds like I need to
revisit these and change the way I handle this kind of data. I'm just
not sure what approach I should be using nowadays.
Usually, such things are located in relation to a class in
a jar file, often the "Main" class of the "program." Without more
specifics, I can't say whether that makes sense for (or to) you.
I could certainly put the web-safe colors in an Enum. I'm not clear
yet on the rest though.
Let's say that I want to pre-define some ColorSets that would ship
with program. But customers would also be given a program that would
generate additional ColorSets. However, all ColorSets, including the
ones I define and the ones they define, need to choose their colors
from the set of web-safe colors. How should that be done? I'm not
quite picturing what you have in mind yet.
enum SafeColor {
// define instances for all (and only) the safe colors
}
then
public interface ColorSet implements Set<SafeColor> {
...
}
or
public interface ColorSet {
SafeColor getSafeColorByName(String name);
SafeColor getSafeColorByHue(Color hue);
SafeColor getNearestSafeColor(Color hue);
...
}
Since the methods must return SafeColors, you can be sure they
return nothing that isn't in the enum you defined. If there's
some "default" implementation to go with this stuff, make
ColorSet a class (abstract optional) instead of an interface.
Another example of the same issue might be two-letter country codes.
Given that there is a list of recognized two-letter country codes,
'us' for United States, 'ca' for Canada, etc., how could I ensure that
a group of country codes - let's say, a list of North American
countries - only contains legitimate country codes like 'us' and 'ca'
and no non-existent codes, like 'xx'? [...]
One way would be to have a Country class, with a static
method like `Country getCountryForCode(String countryCode)'.
The caller hands it a (supposed) country code, and it returns
the designated Country or null (or throws up, if you prefer).
I do not see how an interface would be of any help here.
Fair enough. I expect that I am still thinking in obsolete ways. An
enum that lists all valid country codes could easily be used to
validate a country code that someone proposed to type on a form, for
example. Have the form validations check the country code provided on
the form (I'm assuming a simple text box here, rather than a List) to
see if it's in the Enum; if it is, it's a valid code and if it's not,
the country code is invalid. But this time you suggested a class with
a static method, not an Enum. Is that because the list of countries is
mutable whereas the list of web-safe colors is immutable?
Mostly. You could use a Country enum if you liked, at the
cost of having to recompile and ship a new version of Country
whenever something changed. A Country class that initialized
itself by reading a code/country list from some resource might
be easier to mutate. (The resource might even be a URL somewhere,
saving you the effort of "pushing" new files to the installed base.)
There's more than one way to skin a cat. Which is a good
thing, because cats come in different sizes and ferocities ...
--
Eric Sosman
esosman@ieee-dot-org.invalid