私は C++ で書かれた別のライブラリを拡張するライブラリを作成しましたが、現在、このライブラリを Java に移植しています (C++ が上に書かれた元のライブラリは Java に既に存在します)。C++ コードには、Stallable電圧入力のデルタが与えられたモーター コントローラーにストール検出を追加するために使用される、純粋な仮想クラスが呼び出されています。getVoltage()このクラスには、いくつかの異なるモーター コントローラー クラスであるため、電圧源を供給するために使用される純粋な仮想メソッドと、失速があるかどうかを判断するためのいくつかの仮想関数が含まれています。
クラスは、このクラスだけでなく、元のライブラリのクラス (コードにアクセスできず、すべての意図と目的のために変更できないもの) をサブクラス化し、実装しgetVoltage()、他のメソッドをオーバーライドします。好きかもしれません。次に、これらのオブジェクトは、ストールがあるかどうかを尋ねることができます。
Java 側からこの問題に取り組むと、私の状況はもう少しトリッキーになります。私はまだ元のクラスに触れることができないので、コードのリファクタリングはオプションではありません。私のライブラリのユーザーは、適切と思われる方法でサブクラス化または実装することを引き続き許可する必要がありますStallable。
現在、私が見ている見通しは次のとおりです。
- インターフェイス
Stallableを作成し、それが使用するストール検出ロジックを再実装します。C++ コードベースが持つ元の機能を作成するには、クラスに元のライブラリをサブクラス化し、実装する必要がありますStallable。これは機能しますが、元の純粋な仮想 C++ のロジックを、Stallable私が含めるサブクラスとエンド ユーザーが作成するサブクラスの間で再実装する必要があります。 Stallable元のライブラリのモーター コントローラー クラスへのオブジェクト参照を保持する抽象クラスを作成します。これにより、一部のメソッドをオーバーライドする必要があり、一部のメソッドをオプションでオーバーライドするなど、C++ コードの機能の一部が保持されますが、このコードと C++ コードの間で透過性が失われます。C++ では、すべてのサブクラスがStallable元のモーター コントローラーから派生したものであるため、モーター コントローラーが必要な場合やオブジェクトが必要な場合に、オブジェクトへのポインターを簡単に移動できるようになりましたStallable。この場合、各Stallableサブクラスが保持する元のモーター コントローラーへの Java 参照を返す何らかのタイプのアクセサー関数を実装する必要があります。透明性は失われますが、失速検出は簡単に追加できます。
明らかに、さまざまなモーター コントローラーの元のクラスを変更できれば、この問題は C++ コードのリファクタリングで簡単に解決できます。
両方の言語の OOP へのアプローチの相違点を調査した結果、エンド ユーザーとStallable含める予定の実装に追加される摩擦にもかかわらず、オプション 2 を使用する傾向があります。Stallable.java を書き始める前に、他にもっと良いアイデアや洞察がないか尋ねていました。