Java：封装库的自动方式
我有以下场景：出于特定目的，我在 Eclipse RCP 应用程序中使用一个非常大的外部库。
目前，我不确定将来是否不必将此库替换为另一个库（因为它不提供必要的功能或类似的功能）。另外，我有用户从第一天起就使用这个库，所以我想封装该库，至少给我一个将来更改该库的机会，而用户不会注意到或不必更改其代码中的任何内容。
有没有一种简单的方法以某种自动化方式封装整个库？
I have the following scenario: I am using a very big external library in my Eclipse RCP application for a specific purpose.
At this point in time I am not sure if I may not have to replace this library in the future to another one (because it does not provide the necessary functionality or something like that). Also I have users using this library from day one so I would like to encapsulate the library, giving me at least a chance of changing the library in the future without the user noticing or having to change anything in their code.
Is there a simple way to encapsulate a whole library in some automated fashion?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您实际使用的库接口部分完全无关紧要，或者按照 JSF 或 JAX-B 的方式进行标准化（在这种情况下您不需要封装），否则这完全是浪费精力。
我可以保证，如果您必须切换到不同的库，封装将被证明毫无价值，因为另一个库具有不同的底层概念和使用模式，无法适应现有的库。
Unless the part of the library's interface you are actually using is completely trivial, or standardized the way JSF or JAX-B are (in which case you don't need encapsulation) this is a completely wasted effort.
I can guarantee that if you have to switch to a different library, the encapsulation would prove worthless because the other library has different underlying concepts and usage patters that cannot be made to fit the existing ones.
我认为这是不可能的，因为该库的语法和语义在某种程度上可能是唯一的。
当然，您可以为所有类创建代理并提供这些代理，但这可能需要相当多的工作（编写一个扫描库的框架），并且这并不能保证您交换库会很容易。
想象一下替换将提供不同的方法，甚至使用不同的语义（在某种程度上）。如果替换中缺少方法/字段等怎么办？
处理这个问题的最佳方法是编写一个显式包装器并让用户仅使用该包装器。通过这种方式，您可以将 API 限制为真正需要的核心概念。然而，根据库的实际用途，这仍然可能无法提供足够好的封装。
示例：
对于 3D 编程，您可以使用 OpenGL 或 Direct3D。两者的 API 略有不同，但使用相同的核心概念。因此，您可以为它们创建一个提供统一 API 的包装器。然后，该包装器可能必须转换一些数据等（例如使面向列的矩阵面向行，反之亦然），但由于核心概念是相同的，所以这应该是可行的。
但是，您需要坚持核心概念，并且不能使用其他功能。例如，Direct3D 还将提供一些 OpenGL 未提供的更高级的 API (Direct3DX)。
I don't think that's possible, since the syntax and semantics of the library might be unique to some extent.
Sure, you could create proxies for all the classes and provide those, but that might require quite some work (writing a framework that scans the library) and that wouldn't guarantee you that exchanging the library would be easy.
Imagine the replacement would provide different methods and even use different semantics (to some extent). What if methods/fields etc. were missing in the replacement?
The best way to handle that would be to write an explicit wrapper and make the users use only that wrapper. This way you could restrict the API to the core concepts that are really needed. This still might not provide a good enough encapsulation however, based on what the library actually does.
Example:
For 3D programming you could use OpenGL or Direct3D. Both have somewhat different APIs but use the same core concepts. Thus you could create a wrapper for them that provides a unified API. That wrapper might then have to convert some data etc. (like making column-oriented matrics row-oriented and vice versa) but since the core concepts are the same, that should be doable.
However, you'd need to stick to the core concepts and couldn't use additional features. For example, Direct3D would also provide some more highlevel API (Direct3DX) which isn't provided by OpenGL.