.Net で拡張メソッドを使用するためのベスト プラクティスは何ですか?

Question

私はこれらがあらゆる方法で使用されているのを見てきましたし、間違った方法で使用していると非難されました（ただし、その場合、私はその方法を使用して、 ポイント).

それでは、拡張メソッドを採用するためのベスト プラクティスは何だと思いますか?

開発チームは拡張メソッドのライブラリを作成し、それをさまざまなプロジェクトにデプロイする必要がありますか?

オープンソース プロジェクトの形式で一般的な拡張メソッドのコレクションが必要ですか?

アップデート：組織全体の拡張メソッド ライブラリを作成することにしました

Answer 1

近々リリースされるフレームワーク設計ガイドライン第 2 版には、拡張メソッドの実装に関するいくつかのガイダンスが含まれる予定ですが、一般的には次のとおりです。

拡張メソッドは「意味的に意味がある場合」にのみ定義する必要があり、あらゆる実装に関連するヘルパー機能を提供します。

また、すべての .NET 言語が拡張メソッドを拡張として呼び出すことができるわけではないため、System.Object の拡張も避けてください。(たとえば、VB.NET では、静的拡張クラスの通常の静的メソッドとして呼び出す必要があります。)

インターフェイスを拡張する場合を除き、拡張型と同じ名前空間に拡張メソッドを定義しないでください。

「実際の」メソッドと同じシグネチャを持つ拡張メソッドは呼び出されないため、定義しないでください。

Answer 2

見てみるといいかもしれません http://www.codeplex.com/nxl そして http://www.codeplex.com/umbrella どちらも拡張メソッド ライブラリです。私は個人的にソースコードを見たことがありませんが、そこにいる人たちがいくつかの良いヒントを提供してくれると確信しています。

Answer 3

私のフレームワークを使用している人にはこのメソッドが便利だと思われる可能性が高いため、Utils クラスのコア ライブラリに拡張メソッドを含めてきましたが、エンド開発者が拡張メソッド ライブラリを選択できる大規模展開の場合は、すべての拡張機能を独自の名前空間、さらには独自のプロジェクト ファイルに配置して、参照や using ステートメントを追加したり、必要に応じて単に追加したりできるようにすることをお勧めします。

Core.Extensions.Base64Encode(str);

私の Utils クラスは私の全世界での親友です。それは拡張メソッドが登場する前のことであり、拡張メソッドは私たちの関係を強化するのに役立っただけです。私が従う最大のルールは、可能な限り、どの拡張フレームワークを使用するかについて人々に選択肢を与えることです。

Answer 4

Objective-C 言語には 1990 年代初頭から「カテゴリ」がありました。これらは本質的に .NET 拡張メソッドと同じものです。ベスト プラクティスを探すときは、Objective-C (Cocoa および NeXT) 開発者がそれに基づいてどのような経験則を考案したかを確認するとよいでしょう。

ブレント・シモンズ (Mac OS X および iPhone 用 NetNewsWire RSS リーダーの作者) は本日、彼の記事について投稿しました。 カテゴリの使用に関する新しいスタイル ルール そして少しありました Cocoa コミュニティでのディスカッション あのポストのあたり。

Answer 5

それは拡張メソッドがどのような目的に役立つかによると思います。

• プロジェクトの特定のビジネス ニーズに関連する拡張メソッド (基本データ型またはカスタム オブジェクトに接続されているかどうか) は、複数のプロジェクトに分散されるライブラリに含めるべきではありません。
• 基本的なデータ型 (int、string など) またはより幅広い用途を持つジェネリックスに関連する拡張メソッドは、パッケージ化してプロジェクト全体に分散できます。

ほとんど用途のない拡張メソッドをグローバルに含めないように注意してください。拡張メソッドはインテリセンスを詰まらせるだけであり、混乱や誤用を引き起こす可能性があります。

Answer 6

私が初めて拡張機能について知ったとき、本当に使いすぎて乱用していました。

ほとんどの場合、私はさまざまな理由から、拡張メソッドの使用を避け始めています。

私がそれらの使用をやめた理由のいくつかは、「所有していない型を拡張する前によく考えてください」など、上記の Scott のブログ リンクに記載されています。拡張している型のソースを制御できない場合、プロジェクトを新しい .NET バージョンに移動するなど、ソース型に追加や変更があった場合に、将来問題や衝突が発生する可能性があります。新しい .NET バージョンに拡張機能と同じ名前の型のメソッドが含まれている場合、誰かが破壊される可能性があります。

私が拡張メソッドの使用をやめた主な理由は、コードを読んだだけでは、メソッドのソースがどこにあるのか、誰がその「所有者」なのかをすぐに判断できないためです。

コードを読んだだけでは、そのメソッドが拡張機能なのか、それともその型の標準的な NET API メソッドなのかはわかりません。

インテリセンス メニューは、すぐに非常に煩雑になる可能性があります。