私は最近 WPF を使い始めましたが、多くのキャスト (特にイベント) を行う必要があることに気付きました。これは審美的な問題ですが、通常のキャストを使用する代わりに、拡張メソッドを使用してキャストする場合、どれほど悪いか疑問に思っていました。
public static T Cast<T>(this object obj)
{
return (T)obj;
}
これは、いくつかのネストされた括弧を防ぎ、次のように変更できることを意味します。
Console.WriteLine(((DataGridCell)e.OriginalSource).ActualHeight);
に：
Console.WriteLine(e.OriginalSource.Cast<DataGridCell>().ActualHeight);
私が見落としているかもしれない明確な欠点はありますか？コードでこれに遭遇したとき、人々はどれほどうんざりするでしょうか? :)
これは意図的に に似ているEnumerable.Castので、必ずしも人々が嫌悪感を抱くとは言えません。
私が見落としているかもしれない明確な欠点はありますか？
主な欠点は、これがコード内のすべての変数で使用できる拡張メソッドになることですSystem.Object。Objectインテリセンスを「汚染」するため、私は通常、この理由で拡張メソッドを避けます。
そうは言っても、他にも次のような欠点があります。
これを既存の で使用するIEnumerableと、 と名前が競合しEnumerable.Cast<T>ます。あなたの名前空間が含まれているが が欠けているファイルは、using System.Linq他の開発者に簡単に誤解される可能性がありますCast<T>。
値の型でこれを使用すると、ボクシング (値の型をオブジェクトにプッシュする) が導入され、次にボックス化解除とキャストが導入されます。これにより、キャストでは発生しない例外が実際に発生する可能性があります。次の場合、拡張メソッドで例外が発生します。
int i = 42;
float f = i.Cast<float>();
float f = (float)i;完全に合法であるため、これは予想外かもしれません。詳細については、Eric Lippert のRepresentation and Identityに関する投稿を参照してください。これを書く場合は、演算子にクラス制約を追加することをお勧めします。
個人的には、括弧を使用します。これは共通の言語サポート機能であり、すべての C# 開発者が理解できるはずです。キャストには、短く、理解しやすく、副作用がないという利点があります (インテリセンスなどに関して)。
他のオプションは、これを通常の静的メソッドにすることです。これにより、次のように記述できます。
Console.WriteLine(Utilities.Cast<DataGridCell>(e.OriginalSource).ActualHeight);
これにより、インテリセンスを「汚染する」という欠点が解消され、それがあなたが作成したメソッドであることが明らかになりますが、使用するために必要な入力の量が増えます。また、ボックス化およびボックス化解除/キャストの問題を防ぐこともできません。
主な欠点は、キャストがすべての C# 開発者にとってよく知られている一方で、Cast<T>メソッドは発明されていない別の車輪にすぎないことです。通常、次のステップは、、、などの拡張子のセットIsTrueです。IsFalseIsNull
これは構文ゴミです。