Для такого рода вещей я предпочитаю использовать что-то похожее на шаблон Maybe / Option из лагеря функционального программирования.В результате вы получаете интерфейс, подобный следующему:
public abstract class DoubleOrString
{
// Constraint isDouble() xor isString()
public boolean isDouble();
public boolean isString();
//Must throw iff !isString()
public String getString();
//Must throw iff !ifDouble()
public Double getDouble();
public static DoubleOrString wrap(final double wrapMe)
{
return new DoubleOrString()
{
public boolean isDouble() {return true;}
public boolean isString() {return false;}
public Double getDouble() {return wrapMe;}
public String getString() {throw new RuntimeException();}
};
}
//same for wrap(String)
}
. Это вызывает проблему у клиентов, поскольку всегда существует проверка работоспособности, что в соответствующее время действительно имел место тип double или String.В вашем случае я бы сделал только один метод get (), поэтому, когда клиент (думает, что он) знает, что это за тип, вызывается
objectName.get(5).getString();
и в вашем методе get (int),вместо того, чтобы возвращать String или double, оператор return выглядит так:
DoubleOrString.wrap(theThingToReturn)
Это немного дополнительная работа, но в прошлом она меня несколько раз оплачивала.
Вот как вы можете использовать его для его создания (предупреждение - это не было рядом с компилятором)
public static DoubleOrString parseADoubleOrString(String input) {
try {
return DoubleOrString.wrap(Integer.parseInt(input))
} catch (NumberFormatException nfe) {
return DoubleOrString.wrap(input);
}
}
, а вот как выглядит клиент
String input = //get the input from the user somehow
DoubleOrString parsed = parseADoubleOrString(input);
if (parsed.isDouble())
aFunctionThatTakesADouble(parsed.getDouble());
else
aFunctionThatTakesAString(parsed.getString());