泛型行业标准的Java重构

麻省理工学院研究小组的论文可能会为您提供一些有用的指导方针:

• Refactoring Java Applications to Use Generic Libraries
  • Efficiently refactoring Java applications to use generic libraries
    罗伯特·福勒、弗兰克·蒂普、朱利安·杜比、亚当·基尊和马库斯·凯勒
    Ecoop2005---面向对象编程,第19届欧洲会议,(苏格兰格拉斯哥),2005年7月25-29日。
  • Refactoring techniques for migrating applications to generic Java container classes
    Frank Tip、Robert Fuhrer、Julian Dolby和Adam Kiezun
    IBM T.J.Watson研究中心IBM研究报告RC 23238,(美国纽约约克敦高地),2004年6月2日。

我不认为盲目遵循别人宣称的“最佳实践”或“行业标准”是一个好主意。您处于决定更改代码是否值得的最佳位置。

您需要回答的问题是,升级旧代码会带来什么好处,成本是多少,风险是什么?

主要的好处是,您将改进编译时类型检查,这将有助于检测使用更新代码的新代码中的错误。它甚至可能突出显示现有代码中的错误。使用泛型的代码虽然有时很冗长,但通常更易于阅读,因为它明确了哪些类型在哪些上下文中有效。您也不再需要取消/忽略编译器警告。

成本是进行和测试引入泛型所需的更改所需的时间。任何时候修改代码都有可能引入错误,所以这是一个风险。利益大于成本吗?这取决于你有多少代码,它是如何被使用的,以及你对时间的其他要求。

使用Java泛型绝对是个好主意。它是向后兼容的。因此,无法转换的代码库将继续使用新代码。

编辑 :我应该提到 type erasure 作为使向后兼容的原因。

采用仿制药的最佳实践?第一个最佳实践是“做”。尽量从代码中消除尽可能多的强制转换。如果你想让你的生活更简单,使用intellij的“generify”重构——只需将它指向你的整个代码库,让它做它的事情,然后在清理之后做一点。

您的团队应该将大规模重构的好处与这样做的成本以及技术和业务风险相平衡…以及你团队的其他优先事项。

不了解您的项目和业务背景的人提出的“最佳实践”论点和意见在这里根本不相关。

最佳实践不存在。这是一个奇怪的术语,它意味着一个特定解决方案的“最佳状态”关闭了门…使用泛型?对。立即。这是一段尴尬的旅程,因为许多大型图书馆(冬眠、春天)仍然无法完全接纳它们。但在我的经验中,处理泛型和勇敢的强制转换的组合仍然比根本不使用它们有更好的代码基础。

我还将制定政策,在您触摸时进行转换,而不是执行某种巨大的重构任务。

使用泛型重构通常是个好主意。

它不是必需的,所以不要将其视为紧急任务,但是您可以考虑不使用泛型是 轻微的技术债务 -因此,如果您有时间,并且代码库计划有一个长期的持续使用寿命,那么值得投资升级它。

主要好处是:

• 更好的编译时类型检查,这将减少错误
• 从源代码中删除不必要的强制转换,这使代码更具可读性。
• 它仍然向后兼容旧代码(由于类型擦除)

没有真正的缺点——我唯一能想到的问题是,如果你想将代码移植到Java的早期版本,而不需要泛型支持。但那将是一件非常不寻常的事情!

如果您确实决定重构为泛型,那么我建议执行以下步骤:

1. 打开所有编译器警告(Eclipse有非常好的警告)
2. 首先将泛型类型添加到类中,例如 MyClass<T>
3. 然后将任何方法签名/内部字段/数据结构的类型更改为使用t
4. 此时,整个代码中可能会出现许多警告/错误。这没关系,只要把它们都修好就行了。通常,您的IDE可以“快速修复”其中许多问题。
5. 编写/重构演示通用特性的测试用例

这是相当快做到这一切-我想我设法重构约10000行的Java库代码使用泛型在不到一天,其中包括更新一些客户端代码。