【发布时间】:2013-11-25 10:16:10
【问题描述】:
我创建了一个从另一个用 C++ 编写的库扩展而来的库,现在我将该库移植到 Java(在 Java 中编写 C++ 的原始库已经存在)。在 C++ 代码中,有一个名为Stallable 的纯虚拟类,它应该用于在给定电压输入增量的情况下将失速检测添加到电机控制器。该类包含一个纯虚方法getVoltage(),用于提供电压源,因为它们是几个不同的电机控制器类,以及一些用于确定是否存在失速的虚函数。
类将继承这个类,以及原始库中的一个类(我无权访问代码并且出于所有意图和目的,否则无法修改),并将实现getVoltage(),并且覆盖他们可能喜欢的任何其他方法。那么这些对象就可以被询问是否有档位。
当我从 Java 方面处理这个问题时,我的情况变得有点棘手。我仍然无法触及原始类,因此重构代码不是一种选择,我的库的用户仍然应该被允许继承或实现Stallable,但他们认为合适。
目前我看到的前景如下。
- 使
Stallable成为一个接口并重新实现它使用的停顿检测逻辑。为了创建 C++ 代码库的原始功能,我必须让类子类化原始库并实现Stallable。这可行,但需要在我将包含的任何子类以及最终用户将编写的任何子类中重新实现原始纯虚拟 C++Stallable中的逻辑。 - 使
Stallable成为一个抽象类,它包含对原始库中电机控制器类的对象引用。这保留了 C++ 代码中的一些功能,因此某些方法必须被覆盖,而一些方法可以选择覆盖,但是在此代码和 C++ 代码之间失去了透明度。在 C++ 中,由于每个子类都是Stallable和原始电机控制器的派生,因此当需要电机控制器和需要Stallable对象时,很容易将指针扔向对象。在这种情况下,必须实现某种类型的访问器函数,该函数返回对每个Stallable子类将保留的原始电机控制器的 Java 引用。透明度会丢失,但很容易添加失速检测。
显然,如果我可以修改各种电机控制器的原始类,那么这个问题很容易成为重构 C++ 代码的问题。
在研究了两种语言的 OOP 方法之间的差异后,我倾向于选择选项 2,尽管它为我的最终用户和我计划包括的 Stallable 实现增加了摩擦。在我开始编写 Stallable.java 之前,我在问是否还有其他更好的想法或见解。
【问题讨论】:
-
您在 OOP 方法之间的差异上是完全正确的。但是,Java 确实具有 import static - 如果您选择使用接口,这可用于减少客户必须实现的代码量。如果您在该接口上添加了一个装饰器类,您可以在那里实现您的纯虚函数。此外,您可以查看 Java Native Access (github.com/twall/jna)。
-
你可以在 java8 中做到这一点。 Stallable 是一个具有一个抽象方法 getVoltage() 和其他包含方法主体的“默认”方法的接口。
-
@zhong.j.yu 我正在以这种方式实施解决方案。我不知道有这样的功能,谢谢。
标签: java c++ oop inheritance interface