21

私は最近かなり拡張メソッドを使用しており、それらの多くの用途を見つけました。私が抱えている唯一の問題は、それらがどこにあり、拡張メソッドを取得するためにどの名前空間を使用するかを覚えていることです。

しかし、私は最近、System 名前空間、System.Collections 名前空間、または意味のある他のシステム名前空間に拡張メソッドを作成することを考えました。たとえば、次のように実装しました。

namespace System
{
    /// <summary>Various array extensions</summary>
    public static class ArrayExtensions
    {
        /// <summary>Converts the array to a hex string</summary>
        /// <param name="value">The value.</param>
        /// <returns>The array as a hex string</returns>
        public static string ToHexString(this byte[] value)
        {
            var hex = new StringBuilder(value.Length * 2);
            foreach (byte b in value)
            {
                hex.AppendFormat("{0:X2}", b);
            }
            return hex.ToString();
        }
    }
}

これは正しいことですか？

4

5 に答える 5

22

フレームワーク設計ガイドライン（第2版）から：

インターフェイスにメソッドを追加する場合や依存関係を管理する場合を除いて、拡張メソッドを拡張タイプと同じ名前空間に配置しないでください。

これはシナリオを明示的にカバーしていませんが、通常、Framework名前空間（または制御できない名前空間）の拡張を避け、代わりにそれらの拡張を独自の名前空間に配置することを選択する必要があります。拡張機能を「グループ化」すること（コレクション拡張機能が一緒になるなど）について強く感じている場合は、サブネームスペースを導入できます。あなたのシナリオでは、コレクションへの拡張はSystem.Collection.Extensions名前空間または名前空間、Company.CollectionsあるいはCompany.Collections.Extension名前空間になります。

拡張メソッドを使用するには、スポンサークラス（拡張メソッドを定義するクラス）を含む名前空間をインポートする必要があります。標準の.NETFramework名前空間の1つに拡張メソッドを追加すると、それらは常に（そして暗黙的に）使用可能になります。

于 2008-11-26T20:20:02.570 に答える
14

将来の変更によってコードが破損する可能性があるため (たとえば、重複を導入することによって)、主に制御できない名前空間を拡張することは避ける必要があります。

私は、すべての子名前空間を自分の作品に属するものとして識別する別のルート名前空間を使用して、標準の名前空間を模倣する傾向があります。ルート名前空間は、あなたの名前、あなたの組織の名前、またはその名前空間の内容があなたのものであることを識別する何かである可能性があります。

たとえば、 を拡張する場合は、またはSystem.Collectionsを使用できます。NickR.CollectionsNickR.System.Collections

于 2008-11-26T19:52:21.067 に答える
4

名前空間が拡張メソッドに実際に影響するのは、可視性と発見可能性だけです。そのため、拡張メソッドを常にその型に表示するかどうかによって異なります。フレームワークの設計ガイドラインは、主に公開 API を対象としているため、一般的にはガイドラインに従うことをお勧めしますが、内部 API の場合はルールを破ることが理にかなっている場合がほとんどです。

たとえばTimeSpan、コードベース全体でオブジェクトを使って多くの作業を行っていますが、フレームワークにはこれらを乗算または除算するメソッドがないため、とりわけ拡張メソッドを追加MultiplyByし、それらを名前空間に配置しました。 a が使用されている場所ならどこでも発見可能。DivideBySystemTimeSpan

一方、Typeオブジェクトを操作するかなりのリフレクション作業も行います。特定の領域では非常に便利ですが、一般的ではない拡張メソッドがたくさんあります。これらはOurCompany.Reflection名前空間に存在するため、具体的にする必要があります。インポートされました。

したがって、内部 API の場合、決定は「コードベースで型が使用可能なすべての場所でこのメソッドを使用できるようにするか?」ということになります。答えが「はい」の場合は同じ名前空間に配置し、そうでない場合は別の場所に配置します。

于 2008-12-01T02:31:02.760 に答える
3

それが間違っているかどうか (あるいは正しいかどうか) はわかりませんが、独自の「拡張機能」名前空間を持っていないのはなぜですか? 次に、すべての拡張メソッドをその名前空間に配置し、一貫性を保ちます。

本当の問題は、それらをどこに置くか、何に名前を付けるか (システムまたはその他の名前空間) ではないと思いますが、一貫性を保ち、常に同じものを使用して問題を回避します (それらがどこにあるかを忘れる)。

于 2008-11-26T19:52:25.293 に答える
0

必要な可視性に応じて、拡張メソッドを名前空間に配置します。そうすれば、発見しやすくなり、通常、名前空間のインポートが少なくなります。

于 2008-12-01T01:31:15.003 に答える