针对不同包中的相同类答案

【问题标题】：Targeting identical classes in different packages针对不同包中的相同类
【发布时间】：2014-03-29 05:58:15
【问题描述】：

我创建了一个支持应用程序的库，但是在最新版本的应用程序中，开发人员更改了结构而没有更改类名。

所以版本 1 的应用程序在包 A 中有 classX，但版本 2 在包 B 中有 classX。我如何以允许在同一构建中支持这两种方式的方式开发我的库？

编辑：我的库依赖于应用程序，而不是相反。

【问题讨论】：

标签： java oop package api-design

【解决方案1】：

这是一个糟糕的决定，如果你仍然想让它工作，你需要提供具有旧结构的骨架类并将调用委托给新版本的类，但它会变得非常脏

最好不如果您对重命名决定坚定，则提供向后兼容性

【讨论】：

主要问题是应用程序不是我能控制的，它是由与我无关的第三方开发的。
@user3474299 所以应用程序不使用你的库，你的库只是控制一些第三方应用程序？
但是 API 是所以不要重命名包，如果真的需要然后在发行说明中声明兼容性
应用程序开发者真的知道你的库的存在吗？
我的库为封闭源程序提供了扩展功能，我使用反编译器和面向方面来访问应用程序中的隐藏方法。开发人员在要求我创建它时知道我的库，但是从那时起他们改变了程序的结构。应用程序被更改的可能性为 0%。

【解决方案2】：

简答：你不能。

真正的答案： 你的库应该能够独立于任何使用它的应用程序而存在。库的目的是提供一组可重用的模块化代码您可以在任何应用程序中使用。如果您的库直接依赖于应用程序类，那么似乎应该认真考虑重新设计，因为您的依赖关系是向后的。例如，让A.classX 和B.classX 都实现您的库提供的某个接口（或扩展某个类），然后让application 传递这些对象的实例，或者Class 用于这些对象，到库。

如果您的“库”不能以这种方式设计，请考虑将其集成到应用程序代码中，使其成为应用程序的直接组成部分，并为您、其他开发人员和其他人提供更好的团队工作流程一起做同一个项目。

快速修复答案：不提供向后兼容性，正如 Jigar Joshi 在 his answer 中所述。

不好的答案：如果你真的需要的话，你可以用反射破解一个脆弱的解决方案。但请注意，从长远来看，“真正的答案”将持续下去。您已经看到当前选择的设计存在问题（因此提出了您的问题），基于反射的解决方案不会阻止这种情况再次发生（甚至是可靠的）。

【讨论】：

我不认为库依赖于应用程序，它是其他方式，OP想要照顾兼容性
@JigarJoshi 嗯；也许我误解了，但我读到它是因为 应用程序 有 B.classX（以前是 A.classX），而库现在已损坏，因为库直接引用了应用程序的 A.classX。这似乎是一个非常奇怪的场景。
@JasonC 有这个正确的方法，如果我表达得不好，对不起
@user3474299 如果应用程序开发人员不愿意与您合作，并且如果向后兼容性并不重要，我建议 Jigar Joshi 的回答——只需将您的库更改为使用 B，用户将拥有更新应用程序。是否有令人信服的理由在这里保持向后兼容性？用户升级是否会成为问题（除了不便，这是您的库中的应用程序开发人员似乎支持不佳的成本）？