我创建了一个库,它扩展了另一个用 C++ 编写的库,现在我正在将这个库移植到 Java(C++ 在其上编写的原始库已经存在于 Java 中)。在 C++ 代码中,有一个名为 Stallable
的纯虚拟类,应该用于在给定电压输入增量的情况下向电机 Controller 添加失速检测。该类包含一个纯虚方法 getVoltage()
用于提供电压源,因为它们是几个不同的电机 Controller 类,以及一些用于确定是否存在失速的虚函数。
类将继承此类,以及原始库中的一个类(我无权访问代码并且出于所有意图和目的,否则无法修改),并将实现 getVoltage( )
,并覆盖他们可能喜欢的任何其他方法。那么这些对象就可以问是否有一个摊位。
当我从 Java 方面处理这个问题时,我的情况变得有点棘手。我仍然无法触及原始类,因此重构代码不是一种选择,我的库的用户仍然应该被允许子类化或实现 Stallable
,但是他们认为合适。
目前我看到的前景如下。
- 使
Stallable
成为一个接口(interface)并重新实现它使用的停顿检测逻辑。为了创建 C++ 代码库所具有的原始功能,我必须让类成为原始库的子类并实现Stallable
。这可行,但需要在我将包含的任何子类以及最终用户将编写的任何子类中重新实现原始纯虚拟 C++Stallable
中的逻辑。 - 使
Stallable
成为一个抽象类,其中包含对原始库中电机 Controller 类的对象引用。这保留了 C++ 代码的某些功能,因此某些方法必须被覆盖,而某些方法可选择被覆盖,但是此代码和 C++ 代码之间的透明度会丢失。在 C++ 中,由于每个子类都是一个Stallable
并且是原始电机 Controller 的派生,因此在需要电机 Controller 时以及在Stallable 时很容易将指针扔到对象上
需要对象。在这种情况下,必须实现某种类型的访问器函数,以返回对每个Stallable
子类将保留的原始电机 Controller 的 Java 引用。透明度会丢失,但可以轻松添加失速检测。
显然,如果我可以修改各种电机 Controller 的原始类,这个问题很容易成为重构 C++ 代码的问题。
在研究了两种语言的 OOP 方法之间的差异之后,我倾向于选择选项 2,尽管它给我的最终用户和我计划包括的 Stallable
实现增加了摩擦。在我开始编写 Stallable.java 之前,我在问是否还有其他更好的想法或见解。
最佳答案
那么基本上您想要的是您的库的 Java 用户能够实现接口(interface)和行为吗?这听起来像是 AOP(面向方面编程)的工作。使用 AOP(例如 AspectJ),您可以将方法注入(inject)符合特定条件的类。
在您的情况下,标准是“实现 Stallable 接口(interface)”。 AOP 的问题在于它是侵入性的。如果您选择运行时编织,您的用户将需要使用 AOP 编译他们的类或将 AOP 添加到他们的类路径。
另一种选择是尝试使用动态代理进行一些委托(delegate)。
最后,你可以尝试使用字节码操作 http://asm.ow2.org/以便在运行时生成类。
如果您编写一个 Java 代码应该是什么样子的示例,也许我的回答会不那么模糊。
关于java - 将多继承 C++ 代码移植到 Java,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19943169/