Экземпляры перечисления Java с разным количеством аргументов - PullRequest
0 голосов
/ 04 марта 2019

Есть ли способ, с помощью которого я могу иметь Enum в Java, чтобы принимать различное количество аргументов, чтобы достичь этого без использования varargs.

public enum ValueType {
    LITERAL() {
        @Override
        String getRepresentation(String... args) {
            return MvelStringUtil.representAsLiteral(args[0]);
        }
    },

    NUMBER() {
        @Override
        String getRepresentation(String... args) {
            return args[0];
        }
    },

    //converts a string representation of a date to a java.util.Date representation, because this is what is required
    DATE() {
        @Override
        // should have two params, 1- date in string, 2- format of the passed string
        String getRepresentation(String... args) {
            // DateUtil.parse accepts dateInString and dateFormat.
            return DateUtil.parse(args[0], args[1]).toString();
        }
    };

    abstract String getRepresentation(String... args);
}

Здесь LITERAL и NUMBER принимают только один аргумент,то есть целевое значение, тогда как экземпляр DATE принимает два.Я прошел несколько вопросов только для того, чтобы выяснить, что этого нельзя достичь с помощью Generics, поскольку перечисления не поддерживают Generics до такой степени.

Кроме того, с точки зрения дизайна, я мог бы просто не иметь все типы в Enum, а иметь их в классе с некоторыми обходными путями, имея в виду, что этот экземпляр ValueType необходимо было разобрать из метода json и getRepresentationбудет вызван для экземпляра unmarshalled enum, чтобы получить фактическое представление целевого значения.

Ответы [ 2 ]

0 голосов
/ 04 марта 2019

Как говорят другие ответы, это невозможно.Цель состоит в том, чтобы убедиться, что вы не получите неправильное количество аргументов для данного типа, чтобы ошибки в вызывающем коде скоро появлялись, верно?

Я бы пошел с простой проверкой в ​​каждой getRepresentationреализация метода .Проверьте длину массива и выведите исключение , если неверно .

Таким образом, правила валидности держатся близко к предмету, который удобочитаем.Вы не будете знать ошибки во время компиляции, но, по крайней мере, вы узнаете их в самом начале.

Перспектива дизайна рекламы - я бы сохранил перечисление.Количество типов ограничено, известно во время компиляции, и после быстрой проверки перечисления каждый узнает, какие есть возможности ...

0 голосов
/ 04 марта 2019

Это невозможно, потому что LITERAL, NUMBER и DATE соответствуют интерфейсу перечисления ValueType.Если бы это было возможно, безопасность типа была бы нарушена здесь:

LITERAL()
{
    @Override
    String getRepresentation(String args) {
        return MvelStringUtil.representAsLiteral(arg);
    }
}    
...
ValueType x = ValueType.LITERAL;
x.getRepresentation("a","b"); // the compiler could not know whether this is syntactically correct
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...