简体繁体 English

针对不同包中的相同类

[英]Targeting identical classes in different packages

原文 2014-03-28 21:26:56 3 2 java/ oop/ package/ api-design

I have created a library which supports an application, however in the newest version of the application the developer has changed the structure without changing the class names. 我创建了一个支持应用程序的库，但是在该应用程序的最新版本中，开发人员已更改结构而未更改类名。

So version 1 of the application has classX in package A but version 2 has classX in package B. How can I develop my library in a way which allows supporting both of these in the same build? 因此，该应用程序的版本1在程序包A中具有classX，而版本2在程序包B中具有classX。我如何以允许在同一版本中同时支持这两个程序的方式来开发我的库？

Edit: My library is dependent on the application, not the other way around. 编辑：我的库依赖于应用程序，而不是相反。

2 个解决方案

That is a bad decision, if you still want to make it work you need to provide skeleton classes with old structure and delegate calls to new version of class but it would get very dirty 这是一个错误的决定，如果您仍然想使其工作，则需要为骨架类提供旧的结构，并委托对新版本的类的调用，但这会变得很脏

better to not provide backward compatibility if you are firm with the renaming decision 如果您对重命名决定坚决，最好不要提供向后兼容性

Short answer: You can't. 简短的回答：不能。

Real answer: Your library should be able to exist independently of any application that uses it. 真正的答案： 您的库应该能够独立于使用它的任何应用程序而存在。 The purpose of a library is to provide a set of reusable, modular code that you can use in any application. 库的目的是提供可以在任何应用程序中使用的一组可重用的模块化代码。 If your library is directly dependent on application classes, then it seems like a redesign should be seriously considered, as your dependencies are backwards. 如果您的库直接依赖于应用程序类，则似乎应该认真考虑重新设计，因为您的依赖关系是向后的。 For example, have A.classX and B.classX both implement some interface (or extend some class) that your library provides, then have the application pass instances of those objects, or Class 's for those objects, to the library. 例如，让A.classX和B.classX都实现您的库提供的某些接口（或扩展某些类），然后让应用程序将这些对象的实例或这些对象的Class传递给库。

If your "library" can't be designed this way then consider integrating it into application code, making it a direct part of the application, and come up with a better team workflow for you, the other developer, and others to work on the same project together. 如果您无法通过这种方式设计“库”，请考虑将其集成到应用程序代码中，使其成为应用程序的直接组成部分，并为您，其他开发人员和其他人提供更好的团队工作流程同一项目。

Quick fix answer: Do not provide backward compatibility, as Jigar Joshi states in his answer . 快速解决方案答案：不像Jigar Joshi在其答案中所指出的那样提供向后兼容性。

Bad answer: You could hack a fragile solution together with reflection if you really had to. 错误的答案：如果确实需要，可以将脆弱的解决方案与反思结合在一起。 But please note that the "real answer" is going to last in the long run. 但是请注意，“真正的答案”将长期持续下去。 You are already seeing the issues with the design you have currently chosen (hence your question), and a reflection based solution isn't going to prevent that from happening again (or even be reliable). 您已经看到您当前选择的设计存在问题（因此，您的问题），并且基于反射的解决方案不会阻止这种情况再次发生（甚至可靠）。