IComparableインターフェースは時代遅れ/「有害」ですか？

IComparable 一方向にしか機能しない

Employeeクラスがあるとしましょう。1つのビューでは、すべてEmployeesを名前でソートし、別のビューではアドレスでソートして表示します。どうやってそれを達成するつもりですか？ではなくIComparable、少なくとも慣用的な方法ではありません。

IComparable ロジックが間違った場所にある

を呼び出すことにより、インターフェースが使用され.Sort()ます。Customer名前で並べ替えられたビューでは、並べ替え方法を示すコードはまったくありません。
一方、Customerクラスは、どのように使用されるかを想定しています-この場合、名前でソートされたリストで使用されることを想定しています。

IComparable 暗黙的に使用されます

代替と比較して、比較ロジックがどこで使用されているか、またはまったく使用されているかどうかを確認することは非常に困難です。標準IDEを想定し、Customerクラスから始めて、

1. へのすべての参照を検索 Customer
2. リストで使用されている参照を見つける
3. それらのリストが.Sort()それらを呼び出したことがあるかどうかを確認します

さらに悪いことに、IComparableまだ使用されている実装を削除しても、エラーや警告は表示されません。あなたが得る唯一のものはあなたが考えるにはあまりにもあいまいだったすべての場所で間違った行動です。

これらの問題が組み合わさり、要件が変わります

私がこれについて考えるようになったまさにその理由は、それが私にとって間違っていたからです。私はIComparable2年前からアプリケーションで喜んで使用しています。ここで、要件が変更され、物を2つの異なる方法でソートする必要があります。前のセクションで説明した手順を実行するのは面白くないことに気づきました。

質問

これらの問題により、代替手段ではうまく機能しない有効なユースケースが見られないという点で、またはにIComparable劣ると考えるようになります。LINQまたはLINQ を使用する方が常に良いのですか、それとも、ここで見られない利点/ユースケースがありますか？IComparer.OrderBy()
IComparer

IComparableあなたが言及した制限があります、それは正しいです。これは、.NET framework 1.0ですでに利用可能なインターフェイスであり、これらの機能的な代替手段とLinqは利用できませんでした。それで、はい、主に後方互換性のために保持されている時代遅れのフレームワーク要素としてそれを見るかもしれません。

ただし、多くの単純なデータ構造では、ソートの1つの方法でおそらく十分または自然です。これらのケースでは、順序関係を実装する標準的な場所を1つ持つことは、コードをDRYに維持するための優れた方法であり、場所を問わずすべての呼び出しで同じロジックを常に繰り返すのではありませんOrderBy。

あなたが書いたように、「2年前からアプリケーションでIComparableを喜んで使用している」ので、私には長い間役立ったようです。のすべての呼び出しを検証、変更、およびテストSortする必要がある場合、それは多くの場所で同じ種類のソートロジックを実行していた兆候である可能性がありますが、これはの障害ではありませんIComparable。そのため、このロジックを1か所に集中させて、コードをよりドライにできます。

についてのあなたの感情に同意します IComparable

上のコメントを見てください Array.Sort()

• 配列の各要素は、配列IComparable内の他のすべての要素と比較できるようにインターフェースを実装する必要があります。（または例外がスローされます）
• ソートが正常に完了しない場合、結果は未定義です。

おそらく今はモチベーションにならないでしょう。しかし！object.Equals()オブジェクトを互いに比較して「同じ」かどうかを確認できるメソッドをすべてのオブジェクトで検討する

既にそこにありArray.Sort()ますが、追加が必要な場合があります。object.Compare(object)