問題:Javaオブジェクト間で双方向の多対1の関係を維持します。Javaの単純なデータベースのようなコレクションクラス
グーグル/コモンズコレクション双方向マップのようなものに、私はにしたいが、前方側の重複する値を許可し、セット裏側値として前進キーのを持っています。このような 使用される何か:
// maintaining disjoint areas on a gameboard. Location is a space on the
// gameboard; Regions refer to disjoint collections of Locations.
MagicalManyToOneMap<Location, Region> forward = // the game universe
Map<Region, <Set<Location>>> inverse = forward.getInverse(); // live, not a copy
Location parkplace = Game.chooseSomeLocation(...);
Region mine = forward.get(parkplace); // assume !null; should be O(log n)
Region other = Game.getSomeOtherRegion(...);
// moving a Location from one Region to another:
forward.put(parkplace, other);
// or equivalently:
inverse.get(other).add(parkplace); // should also be O(log n) or so
// expected consistency:
assert ! inverse.get(mine).contains(parkplace);
assert forward.get(parkplace) == other;
// and this should be fast, not iterate every possible location just to filter for mine:
for (Location l : mine) { /* do something clever */ }
単純なJavaのアプローチがあります。1.いずれかMap<Location, Region>
またはMap<Region, Set<Location>>
として、関係の片側のみを維持し、必要なときに反復によって逆の関係を収集するために、または、2.両側のマップを維持するラッパーを作成し、両側を同期させるためにすべての変更呼び出しを傍受します。
1はO(log n)ではなくO(n)であり、問題になっています。私は2でスタートし、すぐに雑草に入った。
これはSQL世界ではほとんどありません(Locationテーブルはインデックス付きのRegionIDカラムを取得します)。通常のオブジェクトにはそれほど些細なことがあります。
私は実際に何をしているのかわからないので、これを答えにするのは嫌ですが、その価値については間違ったデータ構造を使用していると思います。あなたが描いていることは、マップやセットではなく、すべての頂点が他の頂点の任意の数に隣接しているグラフです。あなたは、適切なグラフデータ構造を使用することによって、より良いプログラミングモデル+ランタイムを得るでしょう。おそらく – Juliet
。私がMaps and Setsから得たのは、基本的なセマンティクスとlog-nパフォーマンスです。より良い構造が、物事の漠然としたマップ - アイ "ビュー"を提供すれば、完璧です。 http://jung.sourceforge.net/を検索中です。今すぐ削除された回答のおかげで有望そうです。 – rgeorge
挿入コストは重要ですか? (また、その最後の行のotherset意味ですか?) – Stobor