如你所知，注解驱动的编程越来越多地被纳入我们现在使用的大多数框架中（即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”，那么应用这些注解的顺序就变得很重要了。