如你所知,注解驱动的编程越来越多地被纳入我们现在使用的大多数框架中(即Spring、Lombok等)。
此外,我们有时需要创建自定义注解。(例如,使用aspect -@LogAroundMethods
记录给定类的所有公共方法的进入/退出跟踪)
因此,一个给定的类可以包含大量的注解。
@LogAroundMethod // My custom annotation
@Slf4j // Lombok annotation
@Component // Spring annotation
public class ClientNotificationProxy {
//Code
}
@LogAroundMethod // My custom annotation
@Configuration // Spring annotation
@ConditionalOnClass(NotificationSender.class) // Spring annotation
@EnableConfigurationProperties(MessagingProperties.class) // Spring annotation
@Import({ MongoConfiguration.class, SpringRetryConfiguration.class }) // Spring annotation
public class StarterClientAutoConfiguration {
// Code
}
- 注解的推荐顺序是什么?
- 特定订单是否有任何影响或益处?
4条答案
按热度按时间v09wglhw1#
在几乎所有的情况下,答案都是:“不,命令没有任何效果。
但实际上它有点复杂。
1.考虑到由注解处理器处理的注解,在其他答案中已经指出,它更多地取决于处理器运行的顺序。但是,处理器可以访问AST,这允许它们确定源代码中注解的顺序。因此,理论上,注解处理器可以使生成的代码依赖于顺序,但我不知道任何这样的例子,我认为这是一种糟糕的做法。
1.当在运行时获取元素的注解时,您还可以访问顺序。The docs有更多关于如何确定顺序的信息。因此,实现可以使其行为依赖于顺序。我再次认为这种做法是不好的。唯一的例外可能是可重复的注解,我可以想到这样做是合理的用例。
如果对注解顺序有任何依赖性(这是非常不可能的),则应在注解的JavaDoc中非常清楚地说明。
所以通常你可以自由地订购他们,因为你喜欢。我不知道任何关于注解顺序的样式指南,所以只要让它对你来说合理就行了。
vltsax252#
特定订单是否有任何影响或益处?
据我所知没有。记住注解是如何工作的:某段代码“查看”您的代码,并检查注解的存在。含义:它“获取”一个注解数组,并检查它所关心的注解是否在该数组中。所以秩序应该是无关紧要的。
当然,当我们讨论具有编译时效果的注解时,情况可能有所不同。这样的注解对编译过程本身有影响,因此最坏的情况是,注解的顺序会改变编译过程。
注解的推荐顺序是什么?
为你工作的那个。意思是:和你的团队坐下来,问问自己“我们是否更喜欢一个特定的顺序”。如果是这样,把它写下来,让人们遵循这个规则。
真实的世界示例:我们使用注解来“描述”我们的“对象”的“属性”。在某些时候,我们发现在添加新属性时经常忘记注解X。因为属性是以随机顺序写下来的,因此很难手动处理(我们有很多不同的注解,有时一个属性上有5到10个注解)。
我们的“解决方案”:注解必须按字母顺序排序(当用于这样的“属性”定义时)。我们甚至有一个单元测试来检查排序顺序。此后:所有“属性”定义遵循相同的规则。这对我们来说很好,因为每个人都有同样的期望和心态。
brqmpdu13#
“* 特定订单是否有任何影响或好处?”不,据我所知,没有。正如Joop埃根所指出的,注解处理器或注解扫描器的顺序是重要的部分。
“* 注解的推荐顺序是什么?* ”-如果能够识别通常一起使用的注解模式,我建议将它们分组到一个新的注解中,并使用新的注解。可以通过创建一个新的
publice @interface MyAnnotation
并使用想要分组的注解来注解这个新注解来实现这一点。this answer就是一个例子。ukqbszuj4#
总是看情况。
假设您有一个注解,它初始化了一个类,并使用了标记为“a”、“b”和“c”的特定配置。如果您的目标是创建另一个注解,为以前配置的类注入额外的设置,如“d”,那么应用这些注解的顺序就变得很重要了。