Java注解的可维护性?

8
我的项目正在逐步实现Java注解。其中一半的开发者 - 包括我在内 - 发现使用注解完成任何复杂操作似乎会增加我们的整体维护负担。而另一半团队则认为它们是“最好的工具”。 您对开发团队维护带有注解代码的实际经验是什么?

1
你是如何使用注解的?我认为这里没有一个标准答案,它真的取决于你如何使用它们。 - james
非常好的问题,因为在这种情况下它可能非常重要。Pro-annotations开发人员已经为我们的Web应用程序创建了一个框架。该应用程序使用Spring。注释根据Command对象中的项目自动构建Web表单,并完全避免使用JSP。我最初没有提及它,因为我对一般答案很感兴趣;我同样对具体答案很感兴趣。 - Dean J
我在意识到你把评论复制到这里之前已经回复了下面。 - james
2
在我看来,注解应该用于隐藏样板代码并简化配置。以这种方式使用,我见过一些优秀的自制应用程序。但是它们不应该用于生成需要稍后查看或作为宏替代品的即时代码。对于这种特定用途,注解听起来像是一个坏主意。 - rtperson
“隐藏样板代码”和“即时生成代码”有什么不同?如果注释隐藏了样板代码,那么“某物”会即时生成那些代码。 - james
显示剩余2条评论
5个回答

6

个人经验表明,对于大多数开发人员来说,处理注释比处理标准的Java XML配置要容易得多。对于像JPA和Spring测试这样的事情,它们是绝对的救星。

注释的好处在于它们使得类的配置自我记录。现在,您不必搜索一个巨大的XML文件来尝试弄清楚框架如何使用您的类,而是您的告诉您。

通常,这种变化的问题在于习惯它需要花费时间。大多数人,包括开发人员,都抵制变化。我记得当我开始使用Spring时,前几周我想知道为什么有人会忍受与之相关的头疼。然后,几周后,我想知道我以前怎么能没有它。


4
我觉得这里有两种注解用法 - 一种是提供类的“描述”,另一种是提供类的“依赖项”。
对于在类上使用“描述”注解,我觉得还好 - 这是属于类的内容,而注解可以帮助简化这些信息 - JPA 的注解就属于这种情况。
然而,我不太喜欢“依赖项”注解 - 即使你是在运行时从注解中确定依赖项,而不是在编译时在类中确定依赖项,那么这不会破坏依赖注入吗? (也许是在精神上,而不是在规则上...)
这可能是个人偏好,但我喜欢将所有应用程序的依赖信息放在一个大的 XML 文件中 - 我认为这是“应用程序配置”,而不是“类配置”。我宁愿搜索已知位置,而不是搜索应用程序中的所有类。

1

这主要取决于集成开发环境(IDE)的支持。我觉得应该通过IDE中的检查来保持注解与代码同步,但是对此的支持有些欠缺。

例如,较旧版本的IDEA会在没有使用 @Override 的情况下警告你覆盖了一个函数,但是如果你更改了方法签名(或者超类签名),破坏了它们之间的关系,它并不会删除 @Override 标记。

没有支持的话,我觉得注解是一种给代码添加元数据的麻烦方式。


0

我绝对喜欢注解。我在Hibernate/JPA、Seam、JAXB等任何可以使用的地方都会用到它们。在我看来,没有什么比打开一个XML文件才能找出一个类是如何处理的更糟糕的了。

在我看来,注解让一个类自己说话。而且注解(希望如此)是你的IDE内容助手的一部分,而使用XML配置通常需要你自己摸索。

然而,最终可能取决于XML配置和注解在任何特定库中的实际使用方式(因为大多数库都提供两者),以及使用的注解类型。我可以想象,定义与构建相关的注解(例如文件/URL路径)可能实际上更容易作为XML配置。


0

我个人认为,你提到的特定用例(自动生成Web表单)是注释的一个很好的使用案例。任何一种“框架”场景,在这种情况下,你可以编写简化的代码,并让框架根据一些建议(即注释)来完成繁重(通常是重复性的)工作,我认为这是注释的理想使用案例。

我很好奇为什么你不喜欢在这种情况下使用注释,以及你认为什么是“维护负担”?(我并不是要侮辱你的立场,只是想了解它)。


完全没有受到侮辱。我们曾经使用自定义标签在JSP中完成所有重复/易错的工作,因此它非常轻量级。开发人员对此很熟悉。无论是从10,000英尺还是从床单下面,都不难理解。JSP非常容易跟踪,因此如果出现问题,调试也很容易。新系统很难添加或更改。我们还有一组开发人员将难以学会使用它。当显示出现问题时,通过阅读大多数开发人员不了解的代码来进行调试。 - Dean J
所以,我觉得你的问题不在于注释,而在于使用注释的框架。如果是这样的话,无论你使用注释、配置文件或其他方式,问题都是一样的。 - james

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接