0

うまくいけば簡単な質問：

Map> 構造で内部的に構造化された MultiMap スタイル構造を構築し、メソッドをオーバーライドして内部マップとリストに適切な方法でリダイレクトすることを計画しています (したがって、これはユーザーに対して multiMap として動作します)。もちろん、いくつかの追加機能が可能になるでしょう。特に、Map> または Map> として構造化されたバージョンを使用する場合は、List バージョンが機能するようになった後にそれを実行する可能性があります。

私の懸念は、entrySet() および同様のメソッドです。これらをオーバーライドして、同じ内部データを使用し、remove メソッドを介して伝播するにはどうすればよいですか?

私の疑いでは、これらのセットはマップの remove 関数にリダイレクトする remove 関数を使用して構築されているため、MultiMap の remove 関数を実装すると動作します。誰でもこれを確認できますか？

また、Collections for Maps のいくつかの静的関数も気になります。Collections クラスはどのようにして変更不可能または同期されたフォームを生成しますか? また、MultiMap がこれと互換性があることを確認する方法はありますか?

4

2 に答える 2

1

新しいマルチマップを実装するのではなく、既存のマルチマップを使用することを検討しましたか?

たとえば、Google Guava Multimapと静的ユーティリティ メソッドのMultimapsをご覧ください...

于 2012-06-18T12:14:25.943 に答える
1

それは、マルチマップの作成方法に依存すると思います。

同様のことを行い、基本的にコレクションが値であるマップとして MultiMap を作成しました。内部でマップを使用するだけで、MultiMap は通常のマップになり、すべてのユーティリティは基本的に機能し続けます。

public class MultiMap<K, V, T extends Collection<V>> implements Map<K, T>
于 2012-06-18T10:34:08.750 に答える