問題タブ [extension-methods]

私がやりたいのは次のようなものです。

つまり、生成されたクラスを、継承ではなくプロトタイプを介して、単一のメソッドで拡張したいと思います。

このクラスはWSDLから生成されたものであり、動的クラスではありません。生成されたコードはとにかく上書きされるため、触れたくありません。

簡単に言えば、AS3のC＃3：s拡張メソッドと道徳的に同等のものが欲しいです。

編集：私はaibの答えを受け入れました。なぜなら、それは私が最もよく求めていたものに合っているからです。さらに考えてみると、それは私の問題を実際には解決しませんが、それは間違った質問をする私のせいです。:)また、良い提案のためのupmods。

.Net 3.5の新しい拡張機能により、機能をインターフェイスから分割できます。

たとえば、.Net2.0では

（3.5で）次のようになります：

これは、多くのインターフェイスにとってより優れたメカニズムのように思えます。このコードを共有するための抽象的なベースは不要になり、機能的にはコードは同じように機能します。これにより、コードの保守が容易になり、テストが容易になります。

唯一の欠点は、抽象ベースの実装が仮想である可能性があることですが、それを回避することはできます（インスタンスメソッドは同じ名前の拡張メソッドを非表示にしますか？そうすることでコードが混乱しますか？）

このパターンを定期的に使用しない他の理由はありますか？

明確化：

ええ、私は拡張メソッドの傾向がどこでもそれらで終わることだと思います。ピアレビューをあまり行わずに.Net値型を使用する場合は特に注意が必要です（文字列にあるのは.SplitToDictionary()-と似て.Split()いますが、Key-Value区切り文字も使用していると思います）

そこにはベストプラクティスの議論があると思います;-)

（ちなみに、DannySmurf、あなたのPMは怖いですね。）

ここでは、以前はインターフェイスメソッドがあった拡張メソッドの使用について具体的に質問しています。

私は多くのレベルの抽象基本クラスを避けようとしています-これらのモデルを実装するクラスはほとんどすでに基本クラスを持っています。このモデルは、オブジェクト階層をさらに追加するよりも保守性が高く、過度に結合されていない可能性があると思います。

これは、MSがLinqのIEnumerableおよびIQueryableに対して行ったことですか？

Lisp で map 関数と reduce 関数を模倣する拡張機能をいくつか書いています。

変換関数は、次のようなクラフトを削減します。

これは理にかなっていますか？それはもっと良いでしょうか？

これは単純なものであることを願っています。

System.Web.Mvc.ViewPage< T > クラスに拡張メソッドを追加したいと考えています。

この拡張メソッドはどのように見えるべきですか?

私の最初の直感的な考えは次のようなものです。

解決

一般的な解決策はthis answerです。

System.Web.Mvc.ViewPage クラスを拡張するための具体的な解決策は、一般的な解決策から始めた以下の私の答えです。

違いは、ジェネリックに型指定されたメソッド宣言と、ジェネリック型を参照型として強制するためのステートメントの両方が必要な特定のケースにあります。

MVC ストアフロントに着想を得て、私が取り組んでいる最新のプロジェクトでは、IQueryable の拡張メソッドを使用して結果をフィルター処理しています。

私はこのインターフェースを持っています。

そして私はこの拡張メソッドを持っています

IPrimaryKey を実装するクラス SimpleObj があるとします。SimpleObj の IQueryable がある場合、IPrimaryKey の IQueryable として明示的にキャストしない限り、GetByID メソッドは存在しません。これは理想的とは言えません。

ここで何か不足していますか？

拡張メソッドをどのように編成しますか? オブジェクト クラスと文字列クラスの拡張機能があるとしたら、これらの拡張メソッドをクラス IE に分離したくなります。

私はこれを複雑にしすぎていますか、それとも意味がありますか?

一般的なリストのAddRange関数とConcat関数の違いは何ですか? どちらが推奨されますか？

Zip欠落している関数について尋ねる別の質問に触発されました:

インターフェイスForEachに拡張メソッドがないのはなぜですか? IEnumerableそれともどこか？ForEachメソッドを取得する唯一のクラスはList<>. 欠落している理由はありますか、おそらくパフォーマンスですか？

C＃6アップデート

C＃6?.では言語機能になりました：

以下の質問は古いバージョンにも当てはまりますが、新しい?.演算子を使用して新しいアプリケーションを開発する場合は、はるかに優れた方法です。

元の質問：

nullの可能性のあるオブジェクトのプロパティに定期的にアクセスしたい：

等々...

私はこれを頻繁に使用するので、スニペットがあります。

次の場合は、インラインでこれをある程度短縮できます。

ただし、これは少し不格好です。特に、多くのプロパティを設定する場合や、複数のレベルをnullにできる場合は、次のようになります。

私が本当に必要としているのは??スタイル構文です。これは直接null型に最適です。

だから私は次のことを思いついた：

これにより、次の構文が可能になります。

これにより、これらの呼び出しが簡略化されますが、この種の拡張メソッドをチェックインするかどうかはわかりません。コードが少し読みやすくなりますが、オブジェクトを拡張する必要があります。これはすべてに表示されますが、具体的に参照される名前空間に配置することもできます。

この例はかなり単純な例ですが、もう少し複雑な例では、2つのnull許容オブジェクトのプロパティを比較します。

このように拡張機能を使用する際の落とし穴は何ですか？他のコーダーは混乱する可能性がありますか？これは単に拡張機能の乱用ですか？

私がここで本当に欲しいのはコンパイラ/言語拡張だと思います：

これにより、複雑なケースがはるかに簡単になります。

これは値型に対してのみ機能しますが、null許容の同等物を返すことができます。

以下の簡単なデモは、私がやろうとしていることを示しています。実際のプログラムでは、LINQ to SQL select式のリストを読み取っているため、オブジェクト初期化ブロックを使用する必要があります。データベースから読み取ってオブジェクトに格納したい値がありますが、オブジェクトその値に設定できる単純なプロパティがありません。代わりに、XMLデータストアがあります。

オブジェクトの初期化ブロックで拡張メソッドを呼び出すことができず、拡張メソッドを使用してプロパティをアタッチできないようです。

それで、私はこのアプローチで運が悪いのでしょうか？唯一の選択肢は、基本クラスの所有者にこのシナリオ用に変更するように説得することのようです。

BaseDataObjectをサブクラス化する既存のソリューションがありますが、これにも問題があり、この単純な例には表示されません。オブジェクトは、BaseDataObjectとして永続化および復元されます。キャストとテストは複雑になります。

（mattlantからの）回答の1つは、流暢なインターフェーススタイルの拡張メソッドを使用することを提案しています。例えば：

しかし、これはLINQクエリで機能しますか？