参数数不同的Java枚举实例

是否有任何方法可以让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实例接受两个参数。我问了几个问题，结果发现使用泛型无法实现这一点，因为枚举并不真正支持达到这种程度的泛型

---

另外，从设计的角度来看，我是否可以不将所有类型都放在一个枚举中，而是将它们放在一个具有一些变通方法的类中，请记住，此ValueType实例需要从json中解组，并且将对解组的enum实例调用getRepresentation方法以获取目标值的实际表示形式。

这是不可能的，因为文字、数字和日期符合enum 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

---

正如其他答案所说，这是不可能的。 目标是确保给定类型的参数数量不会错误，这样调用代码中的错误很快就会出现，对吗

我会在每个getRepresentation方法实现中使用简单的验证。检查数组长度，如果不正确，则抛出异常

通过这种方式，有效性规则与主题保持紧密联系，便于阅读。您在编译时不会知道错误，但至少在运行时早期就知道了

---

广告设计视角-我会保持枚举。类型的数量是有限的，在编译时已知，通过对枚举的快速检查，每个人都会知道有什么可能…

将您的参数放在pojo中，例如“RepresentationOptions”，并使用它而不是普通的strings@MarcStröbel我本来可以这么做的，但将来可能会有更多类型添加到枚举中。因此，从设计角度来看，传递所有可能不适用的字段的整个pojo是不合适的，比如说，RepresentationOptions中的：-format字段不适用于LITERAL或NUMBER。只是一个想法。hm，RepresentationOptions作为特定枚举选项的接口和实现？由于枚举似乎不是一种可行的方法，有什么方法可以实现这一点（请记住解组），扩展泛型在这里肯定可以解决我的问题，但它们目前还没有实现。@VishalTyagi：无法更改您重写的函数的签名，这在Java中是不可能的，这是有充分理由的（请参阅我文章中的代码）。您可以通过移除子类中的覆盖注释来重载它，但是您需要非常小心，因为重载在某些情况下可能会导致细微的错误。