私にとっての問題の根本は、Javaが参照を許可しないことです。
問題は簡潔に要約することができます。Blobオブジェクトのリストがあると想像してください。
class Blob {
public int xpos;
public int ypos;
public int mass;
public boolean dead;
private List<Object> giganticData;
public void blobMerge(Blob aBlob) {
. . .
if (. . .) {
this.dead = true;
} else {
aBlob.dead = true;
}
}
}
2つのブロブが十分に近い場合は、それらをマージする必要があります。つまり、比較する2つのブロブの一方が他方の属性を引き継ぐ必要があり(この場合、質量を追加してgiganticDataセットをマージする)、もう一方に削除のマークを付ける必要があります。リストから。
隣接するblobを最適に識別する方法の問題、それ自体がスタックオーバーフローの質問を別にして、blobMerge()ロジックをBlobクラスに保持するにはどうすればよいですか?CまたはC++では、これは簡単です。一方のBlobからもう一方のBlobへのポインターを渡すだけで、「ホスト」は「ゲスト」に対して好きなことを何でも実行できるからです。
ただし、上記のJavaで実装されたblobMerge()は、「ゲスト」Blobのコピーで動作します。これには2つの問題があります。1)giganticDataをコピーするための多額のコストを負担する必要はありません。また、2)「ゲスト」Blobの元のコピーは、含まれているリストに影響を受けません。
私はこれを行うための2つの方法しか見ることができません:
1)すべてを2回実行して、コピーを渡します。言い換えると、BlobAはBlobBをホストし、BlobBはBlobAをホストします。最終的には正しい答えになりますが、必要以上の作業を行っています。
2)blobMerge()ロジックを、含まれているリストを含むクラスに配置します。ただし、このアプローチは、Blob(BlueBlob、RedBlob、GreenBlobなど)のサブクラス化を開始するとスケーリングが非常に悪くなるため、順列ごとにマージロジックが異なります。最終的に、リストを保持する汎用コンテナーにサブクラス固有のコードのほとんどが含まれることになります。
ライブラリを使用してJavaに参照を追加することについて何か見たことがありますが、参照を使用するにはライブラリを使用する必要があるという考えは、私をその考えから遠ざけました。