1

多くの情報源がこの質問について語っていますが、私はその概念をよく理解していません。IDictionaryは一般的であり、その型安全性などです。

EntityFrameworkv5を掘り下げると、LogEntryクラスで以下のように宣言されているプロパティが表示されます。

private IDictionary<string, object> extendedProperties;

問題は、なぜ彼らがHashtableよりもIDictionaryを好むのかということです。したがって、Hashtableは、文字列およびオブジェクトとしてキーも受け取ります。唯一の理由は、IDictionaryを選択してプロパティを多形にすることですか？

前もって感謝します。

4

4 に答える 4

3

現在、を使用する理由はほとんどありませんHashtable。Dictionary<>ほとんどの点でそれよりも優れています。そうでない場合は、通常、どちらよりも目的にかなう、強く型付けされた別のコレクションを見つけることができます。

  • タイプセーフ。
  • ボクシングとアンボクシングの深刻なオーバーヘッドはありません。
  • を実装IDictionary<>します。これは、.NETおよびサードパーティのコードと非常に互換性があります。
  • Hashtable多くの分野よりも優れたパフォーマンスを発揮します。リンクを参照してください： リンク＃1、リンク＃2。

IDictionary<>の代わりにプロパティを入力する理由を尋ねる場合Dictionary<>、それはいくつかの理由によるものです。

  • 特にフレームワークでは、通常の型ではなく、できるだけ頻繁にインターフェイスを使用することが一般的にベストプラクティスと見なされています。
  • インターフェイスの実装をかなり簡単に変更することは可能ですが、依存コードとの互換性の問題を引き起こさずに具象クラスの性質を変更することは困難です。
  • インターフェースを使用すると、共変性と反変性を利用できます。
  • 外部コードはIDictionary<>、具象クラスよりも一般的なインターフェースを消費する可能性が高くなりますDictionary<>。したがって、を使用IDictionary<>すると、他の開発者がプロ​​パティとより適切に対話できるようになります。
  • おそらくもっとたくさんあります。これらは私の頭のすぐ上にあります。
于 2012-06-09T19:12:11.517 に答える
1

そうですね、もし彼らがextendedproperiesをハッシュテーブルを返すものとして定義していたなら、拡張プロパティを使用するすべてのコードを壊したいのでなければ、彼らはずっとそれで立ち往生していたでしょう。

インターフェイスを返すことの全体的なポイントは、メソッドがそれを実行し続ける限り、メソッドがどのように実装されているかは問題ではないということです。

「唯一の理由はプロパティを多形にすることです」は要点を見逃しています。これを行うべきではない理由はほとんどないはずです。インターフェイスを返すことができる場合は、インターフェイスを返します。ほとんどの場合、これは優れた設計です。

于 2012-06-09T18:17:33.137 に答える
1

したがって、ここでの回答のほとんどは、一般的な目的で辞書とハッシュテーブルを比較することに関するものであり、特定の実装を選択した理由ではありません。

その特定の実装では、あなたは正しいです、それは戻り型としてオブジェクトを使用しているので、辞書の強く型付けされた利点は利用できません。

IMOは、New vs Oldに要約されます。ArrayList、Hashtableなどは古い技術であり、多くの機能がないため（他の回答で説明されている）、一般的には大いに嫌われています。これらの機能はこの特定のケースでは使用されませんが、古いテクノロジーに戻すことによる大きなメリットはなく、自己啓発のより良い例を提供します。

つまり、「これが私たちの今のやり方です」ということだけです。

于 2012-06-11T14:02:22.353 に答える
0

HashTableは弱い型であり、Objectのみを返すことができます。Dictionary <>は、格納しているタイプに応じて強く型付けされます。

于 2012-06-09T18:29:20.457 に答える