用于未来类型更改的Java模式

Question

针对预期类型更改进行编程的最佳方法是什么？说，将来我可能不得不使用Joda DateTime而不是Java Date。由于Java不鼓励像typedef这样的反模式，因此确保未来轻松进行重构的最佳方式是什么。
谢谢。

Answer 1

当然，“单一职责原则”或其附近的东西和封装应该有助于限制依赖性蔓延。

但是，基本类型的选择是一个架构决定。如果要更改字符串或整数类型，则希望在代码中进行更改。日期并没有太大的不同。

Answer 2

编程接口和适当的分层是我能想到的最好的防御措施。

当您将完成工作与完成工作分离开来时，只要界面未更改，您就可以在不影响客户端的情况下更改实施。

如果您必须更改界面，或者如果最终导致新问题发生，所有投注都将关闭。没有任何语言具有内置的透视。

Answer 3

将问题中的API /类型封装在wrapper interface的后面，并仅通过包装器使用它。然后，您只需更改包装器代码即可切换实施。

这将是通用的解决方案。然而，Tom正确地指出Date是非常基本的一种类型，所以选择它应该是一个架构决定，而不是经常改变。

Answer 4

听起来像你想要完成“动态重新分类”，
我认为你应该能够实现这个与State pattern。
请到这里查看一个例子：http://cnx.org/content/m17225/latest/

Answer 5

你可以尝试Eclipse的IAdaptable

Answer 6

我拿上这是一个很好的Java IDE可以显着减少数据类型的大规模变化的痛苦。您可以搜索代码使用旧类的点，替换为新类并修复随后发生的编译错误，然后重复。当你完成这些改变后，运行你的单元/回归测试，修正错误并且（碰木头！）你完成了。

好的...可能并不那么简单。特别是：

• 反射依赖关系可能很难找到。
• 外部接线/配置文件中的依赖关系很难找到。
• 由许多人编写/维护的组件组成的大型应用程序可能会有问题。 （你真的不能只是破解大家别人的代码。）

Answer 7

什么是编程 对预期的类型变化的最佳方式。

保持您的设计尽可能简单和干净，并保持一套完整的单元测试。

这可以帮助您与所有未来的变化，包括意想不到的（这是更常见）。