似ているが異なる例から始めます。これは実際の例です。
実際には、たとえばネイティブ C++ ライブラリがある場合、ネイティブ メソッド (各メソッドは C/C++ 関数呼び出しの Java ラッパー) を介してそのライブラリにアクセスする Java クラスを作成し、Java からそのクラスを使用します。(通常、そのラッパー クラスは、概念的な観点からは少し醜いです。つまり、奇妙な補助メソッド、ネイティブ リソース ハンドルなどが含まれています。)
オブジェクト指向の設計とは、責任を割り当てることです。上記の場合、そのネイティブ ライブラリとの対話の責任を 1 つのクラスに割り当てます。次に、アプリケーション ロジックに従って、他のクラスがそのクラスを使用できるようにします。おそらく、そのライブラリ ラッパー クラスのラッパー (より適切なインターフェイスを提供するアダプター) を作成します。
次に、あなたのケースについて。
ほとんどの場合、すでにコード化されているか、直接コード化されている可能性のあるアルゴリズムがいくつかあります。アルゴリズムはできるだけ本に近いものにしておきます。(これは Java のネイティブ ライブラリではなく、本のアルゴリズムのライブラリです。) 次に、このアルゴリズムの本のラッパー クラスを使用する任意のクラスを作成します。
UI に関しては、通常のアプリケーション UI を作成します。データの内部構造 (またはそのデータで発生する可能性のあるイベント) に一致する UI を作成するのは間違っています。「データ準備完了」イベントのみを使用できます。
その理由は、UI の変更がデータとアルゴリズムに影響を与えてはならず、アルゴリズムとデータ構造の変更が UI に影響を与えてはならないからです。