拡張メソッドに関して言えば、クラス名は何もしないように見えますが、名前空間が行うグループ化を提供します。名前空間を含めるとすぐに、名前空間内のすべての拡張メソッドを取得します。したがって、私の質問は次のとおりです。静的クラスにある拡張メソッドから取得できる値はありますか?
それらを静的クラスに入れることがコンパイラの要件であることは理解していますが、組織の観点からは、拡張メソッドをクラスで囲まずに名前空間で定義できるようにすることは合法であると思われます。上記の質問を別の言い方にすると、拡張メソッドをクラスにアタッチするのではなく、名前空間にアタッチすることで、開発者として得られる実用的な利点や助けはありますか?
私は基本的に、直感、確認、または洞察を得ようとしています-拡張メソッドをそのように実装するのが最も簡単であり、拡張メソッドが名前で独自に存在することを許可する時間の価値がなかったのではないかと思います-スペース。
おそらく、Eric Lippert のブログ投稿Why Does C# Implement "Top Level" Methods?に満足のいく答えが見つかるでしょう。(順番に SO の質問Why C# is not allowed non-member functions like C++によって促されます)、whence (私の強調):
「なぜ C# は機能 X を実装しないのですか?」と尋ねられます。いつも。答えは常に同じです。その機能を設計、指定、実装、テスト、文書化、および出荷した人は誰もいないからです。機能を実現するには、これら 6 つのすべてが必要です。それらはすべて、膨大な時間、労力、および費用がかかります。機能は安価ではありません。限られた時間、労力、予算の中で、ユーザーに可能な限り最高の利益をもたらす機能のみを出荷するように努めています。
このような一般的な回答は、おそらく特定の質問に対応していないことを理解しています.
この特定のケースでは、明確なユーザーのメリットは、これまでは言語の複雑さを正当化するほど大きくはありませんでした。異なる言語エンティティが互いにネストする方法を制限することにより、(1) 合法的なプログラムを共通の簡単に理解できるスタイルに制限し、(2) 理解しやすく、指定可能で、実装可能で、テスト可能な「識別子検索」ルールを定義できるようにします。文書化可能。
メソッド本体が常に構造体またはクラス内にあるように制限することで、呼び出しコンテキストで使用される非修飾識別子の意味を簡単に推論できるようになります。そのようなものは、常に現在の型 (または基本型) の呼び出し可能なメンバーです。
私にとって、それらをクラスに入れることは、関連する関数をクラス内でグループ化することです。同じ名前空間に多数の拡張メソッドがある場合があります。DirectoryInfoクラスとFileInfoクラスの拡張メソッドを作成する場合は、DirectoryInfoExtensionsとFileInfoExtensionsというIO名前空間に2つのクラスを作成します。
他の静的メソッドと同じように、拡張メソッドを呼び出すことができます。コンパイラがどのように機能するかはわかりませんが、.net 2用にコンパイルされた場合の出力アセンブリは、従来の.netフレームワークでも使用できます。また、既存のリフレクションライブラリが機能し、変更なしで拡張メソッドを実行するために使用できることも意味します。繰り返しますが、私はコンパイラの専門家ではありませんが、拡張メソッドのコンテキストでの「this」キーワードは、オブジェクトに属しているかのようにメソッドを使用できるようにする構文糖衣を可能にすることだと思います。
他の静的クラス メンバーを内部的に参照できます。
コンシューマー側の側面だけでなく、コードのメンテナンスの側面も考慮する必要があります。
インテリセンスは所有者クラスを区別しませんが、情報はツール ヒントや、IDE に追加した生産性向上ツールを通じて表示されます。これは、そうでなければフラットな (場合によっては非常に長い) リストになるメソッドに何らかのコンテキストを提供するために簡単に使用できます。
消費者の観点から言えば、結論としては、それほど重要ではないと思います。