为@Annotation枚举分配一个值
我创建
enum Restrictions{
none,
enumeration,
fractionDigits,
length,
maxExclusive,
maxInclusive,
maxLength,
minExclusive,
minInclusive,
minLength,
pattern,
totalDigits,
whiteSpace;
public Restrictions setValue(int value){
this.value = value;
return this;
}
public int value;
}
这样我就可以愉快地做这样的事情,这是完全合法的语法。
Restrictions r1 =
Restrictions.maxLength.setValue(64);
原因是,我使用枚举来限制可以使用的限制类型,并且能够为该限制分配一个值。
然而,我的实际动机是在 @annotation 中使用该限制。
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD})
public @interface Presentable {
Restrictions[] restrictions() default Restrictions.none;
}
因此,我打算这样做:
@Presentable(restrictions=Restrictions.maxLength.setValue(64))
public String userName;
编译器会发出声音
The value for annotation enum attribute must be an enum constant expression.
有没有办法完成我希望完成的事情
I created
enum Restrictions{
none,
enumeration,
fractionDigits,
length,
maxExclusive,
maxInclusive,
maxLength,
minExclusive,
minInclusive,
minLength,
pattern,
totalDigits,
whiteSpace;
public Restrictions setValue(int value){
this.value = value;
return this;
}
public int value;
}
So that I could happily do something like this, which is perfectly legal syntax.
Restrictions r1 =
Restrictions.maxLength.setValue(64);
The reason being is, I am using enum to restrict the type of restriction that could be used, and be able to assign a value to that restriction.
However, my actual motivation is to use that restriction in an @annotation.
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD})
public @interface Presentable {
Restrictions[] restrictions() default Restrictions.none;
}
So that, I intended to do this:
@Presentable(restrictions=Restrictions.maxLength.setValue(64))
public String userName;
to which, the compiler croaks
The value for annotation enum attribute must be an enum constant expression.
Is there a way to accomplish what I wish to accomplish
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
你可以这样做:
You can do it like this:
一部分来自编译错误,假设您能够做到这一点。那么您不认为在其他领域应用类似的注释会毁掉第一个领域吗?
我的意思是,
同一个实例现在将具有不同的值,即 32。因此,我相信 64 将丢失。万一,它们在运行时按顺序处理,当我们将值更改为 32、64 时,已经处理了一个。那么我想,我们可以将
mdma
给出的示例中的setter
方法更改为如下所示。A part from compilation error, suppose you are able to do exactly this. Then don't you think applying the similar annotation on some other field will ruin the first one?
I mean to say,
The same instance will now have a different value, that is 32. So, the 64 will be lost, I believe. In case, they are processed on runtime sequentially, and at the time we change the value to 32, 64 one has already been processed. Then I suppose, we can change the
setter
method in the example given bymdma
to something like below.你可以实现你想要的,但不能直接使用枚举。
如果您将 Restriction 设为常规类,并具有私有构造函数和静态常量字段,则您可以使用方法链接来流畅地创建新实例:
然后将其完全按照原始代码使用:
但是,我担心这里缺乏 OO - 如果限制具有不同的行为或定义所需的数据,那么您最终会将所有内容集中在 Restrictions 类中。最好为不同的限制类型创建子类。
You can achieve what you want, but not with enums directly.
If you make Restriction a regular class, with private constructor and static constant fields, you can then use method chaining to create new instances fluently:
Which is then used exactly as your original code:
However, I'm concerned for the lack of OO here - if the restrictions have different behaviour or data needed for definition, then you will end up lumping everything in the Restrictions class. It will be better to create subclasses for the different restriction types.
我选择 Abhin 作为我的问题的答案,因为它是最全面的,并且在我尝试后它很有效。然而,我在这里以回答我自己的问题的形式记录了我实际上做了什么。
重命名 Abhin 的术语,这就是我应用它的方式(类似于 Abhin 的示例):
我认为这太冗长了。我什至可以将其缩写为:
这可能太难以理解,而且仍然过于冗长。我需要的是程序员可以快速而全面地指定的东西:
因此,我决定使用快速而肮脏的方式:
无论如何,我将 Abhin 的答案保留在我的凹处以供将来使用。
I chose Abhin's as the answer to my question because it was the most comprehensive and it worked when I tried it out. However, I document here, in the form of an answer to my own question, what I actually did.
Renaming Abhin's terms, this would be how I would apply it (similar to Abhin's example):
Which I decided is too verbose. I could even abridge it to:
Which might be too incomprehensible and still to verbose. What I needed was something a programmer could specify quickly and comprehensively:
Therefore, I decided to use the quick and dirty:
Anyway, I am keeping Abhin's answer in my recesses for future use.