将多重继承C++代码移植到 Java

我创建了一个库，该库扩展自另一个用C++编写的库，现在我正在将此库移植到Java（编写C++的原始库已经存在于Java中）。在C++代码中，有一个名为Stallable的纯虚拟类，应该用于在给定电压输入增量的情况下向电机控制器添加失速检测。该类包含一个纯虚拟方法getVoltage()用于提供电压源，因为它们是几个不同的电机控制器类，以及一些用于确定是否存在失速的虚函数。

以及原始库中的类（我无权访问代码，并且出于所有意图和目的无法修改），并将实现getVoltage()，并覆盖他们可能喜欢的任何其他方法。然后可以询问这些对象是否有摊位。

当我从Java方面处理这个问题时，我的情况变得更加棘手。我仍然无法触及原始类，因此重构代码不是一种选择，并且我的库的用户仍应被允许以他们认为合适的方式进行子类化或实现Stallable。

目前，我看到的前景如下。

1. 使Stallable成为接口，并重新实现它使用的失速检测逻辑。为了创建C++代码库具有的原始功能，我必须让类对原始库进行子类化并实现Stallable。这将起作用，但需要在我将包含的任何子类以及最终用户将编写的任何子类中重新实现原始纯虚拟C++ Stallable中的逻辑。
2. 使Stallable成为一个抽象类，该类保存对原始库中电机控制器类的对象引用。这将保留C++代码中的某些功能，以便必须重写某些方法，而可以选择重写某些方法，但是此代码和C++代码之间会失去透明度。在C++中，由于每个子类都是原始电机控制器的Stallable和派生，因此当需要电机控制器以及需要Stallable对象时，很容易将指针扔到对象上。在这种情况下，必须实现某种类型的访问器函数，该函数返回对每个Stallable子类将保留的原始电机控制器的 Java 引用。透明度会丢失，但很容易添加失速检测。

显然，如果我能修改各种电机控制器的原始类，这个问题很容易成为重构C++代码的问题。

在研究了两种语言的OOP方法之间的差异之后，我倾向于使用选项2，尽管它为我的最终用户和我计划包含的Stallable实现增加了摩擦。在我开始写Stallable之前，我问是否有其他更好的想法或见解.java。