C＃で統合/システムテストを作成するための小さなライブラリを実装しているときに発生した問題について、あなたの意見に興味があります。ライブラリは、テストオーサリングAPIとテストランタイムAPIの2つの部分で構成されています。テストライターは、オーサリングAPIを使用してテストプランのプロトタイプを作成します。ランタイムは、プロトタイプを取得し、プロトタイプのランタイム表現を作成して実行できます。
RuntimeTestPlanBuilderという名前のクラスをテストできるようにするには、ランタイムオブジェクトモデルクラス全体でEqualsメソッドをオーバーライドする必要がありました。これにより、GetHashCodeメソッドもオーバーライドする必要がある状況になりました。一部のランタイムオブジェクトモデルクラスにGetHashCodeを実装するのは簡単でした。ランタイムモデルの一部のクラスはGetHashCodeを実装するコンテナーであるため、それらは困難であり、不可能でさえありました（たとえば、ランタイムはコンテナーにアイテムを追加できるため、ハッシュコードはO（1）で計算できません）。
その結果、コンテナのユーザーがそれらをキーとして辞書に載せないようにする方法を考えました。私が選んだ解決策は、GetHashCodeメソッドをオーバーライドして、例外をスローすることです。実行時にのみ失敗するため、このソリューションには満足していません。さらに、なぜ.NetFrameworkの設計者がGetHashCodeメソッドをObjectクラスに配置することを選択したのか不思議に思います。コンテナを正当な辞書キーではないものとして適切にマークできないため、この決定が私の状況につながったと思います。
（.Net Frameworkの設計者にとって）より良い決定は、IHashableという名前のインターフェイスをEqualsとGetHashCodeの2つのメソッドで定義し、汎用ディクショナリのItemタイプに制約を付けてインターフェイスを適用することでした。このようにして、コンパイル時にキーがEqualsとGetHashCodeを実装するように強制できます。また、このインターフェースを実装していないクラスは辞書キーとして使用されることを想定していないことは容易に理解できます。
私の質問は次のとおりです。一部のクラスのインスタンスをディクショナリキーとして使用しないように指定するためのより良いソリューション（GetHashCodeから例外をスローしないソリューション）を提案できますか？
ありがとう