あなた自身のクラスのための拡張メソッドをいつ書くべきですか？

私は最近、Addressどこかに、次に別の場所で定義されたデータクラスを持つコードベースを見ました。

fun Address.toAnschrift() = let { address ->
    Anschrift().apply {
        // mapping code here...
    }
}

このメソッドをアドレスに直接指定しないと混乱を招きました。拡張メソッドを使用するときに確立されたパターンまたはベストプラクティスはありますか？それとも、その本はまだ書かれている必要がありますか？

この例のKotlin構文にも関わらず、C＃またはそれらの機能を備えた他の言語にも適用されるので、一般的なベストプラクティスに興味があることに注意してください。

拡張メソッドは、他の方法では実行できないものを提供しません。それらは、実際の技術的な利点を提供することなく、開発をより良くするための構文上の砂糖です。

拡張メソッドは比較的新しいものです。標準と慣例は通常、世論（および何が悪い考えになるかについての長期的な経験）によって決定され、誰もが同意する明確な線を引くことができるようになったとは思いません。

しかし、同僚から聞いたことに基づいて、いくつかの議論を見ることができます。

1.通常、それらは静的メソッドを置き換えます。

エクステンションメソッドは、クラスメソッドではなく、静的メソッドであることに基づいています。それらはクラスメソッドのように見えますが、実際にはそうではありません。

拡張メソッドは、クラスメソッドの代替と見なすべきではありません。むしろ、構文的にはugleの静的メソッドに「クラスメソッド」のルックアンドフィールを与える方法として。

2.目的の方法が、ソースライブラリではなく、消費プロジェクトに固有である場合。

ライブラリとコンシューマーの両方を開発したからといって、適切な場所にロジックを配置しても構わないとは限りません。

例えば：

• あなたは持っているPersonDtoクラスは、あなたからのDataLayerプロジェクト。
• あなたのWebUIプロジェクトが変換できるようにしたいと考えてPersonDtoしますPersonViewModel。

この変換方法をDataLayerプロジェクトに追加することはできません（したくありません）。このメソッドのスコープはWebUIプロジェクトであるため、そのプロジェクト内に存在する必要があります。

拡張メソッドを使用すると、DataLayerライブラリに実装することなく、プロジェクト（およびプロジェクトのコンシューマー）内でこのメソッドにグローバルにアクセスできます。

3.データクラスにデータのみを含める必要があると思われる場合。

たとえば、Personクラスには人物のプロパティが含まれています。ただし、一部のデータをフォーマットするいくつかのメソッドを使用できるようにしたいとします。

public class Person
{
    //The properties...

    public SecurityQuestionAnswers GetSecurityAnswers()
    {
        return new SecurityQuestionAnswers()
        {
            MothersMaidenName = this.Mother.MaidenName,
            FirstPetsName = this.Pets.OrderbyDescending(x => x.Date).FirstOrDefault()?.Name
        };
    }
}

クラスでデータとロジックを混ぜるのが嫌いな同僚をたくさん見ました。データのフォーマットなどの単純なことに同意することはできませんが、上記の例では、Personに依存する必要があるのは不快だと思いSecurityQuestionAnswersます。

このメソッドを拡張メソッドに配置すると、純粋なデータクラスを破壊するのを防ぐことができます。

この引数はスタイルの1つであることに注意してください。これは部分クラスに似ています。そうすることには技術的なメリットはほとんどありませんが、コードがよりクリーンであると考える場合（たとえば、多くの人がクラスを使用しているが、追加のカスタムメソッドは気にしない場合）、コードを複数のファイルに分離できます。

4.ヘルパーメソッド

ほとんどのプロジェクトでは、ヘルパークラスを作成する傾向があります。これらは通常、簡単なフォーマットのためのメソッドのコレクションを提供する静的クラスです。

たとえば、私が働いていたある会社には、使用したい特定の日時形式がありました。すべての場所にフォーマット文字列を貼り付けたり、フォーマット文字列をグローバル変数にしたりする代わりに、DateTime拡張メソッドを選択しました。

public static string ToCompanyFormat(this DateTime dt)
{
    return dt.ToString("...");
} 

通常の静的ヘルパーメソッドよりも優れていますか？私はそう思う。構文をクリーンアップします。の代わりに

DateTimeHelper.ToCompanyFormat(myObj.CreatedOn);

私はそれをできた：

myObj.CreatedOn.ToCompanyFormat();

これは、同じ構文の流暢なバージョンに似ています。どちらか一方を持っていることによる技術的なメリットはありませんが、私はもっと好きです。

これらの議論はすべて主観的です。それらのいずれもそうでなければカバーすることができなかったケースをカバーしません。

• すべての拡張メソッドは、通常の静的メソッドに簡単に書き直すことができます。
• 拡張メソッドが存在しなくても、コードは部分クラスを使用してファイルに分離できます。

しかし、繰り返しになりますが、これらは極端に必要なものではないというあなたの主張を受け入れることができます。

• 特定のクラス用であることを明確に示す名前を持つ静的メソッドを常に作成できるのに、なぜクラスメソッドが必要なのでしょうか。

この質問とあなたの質問への答えは同じです。

• より良い構文
• 可読性の向上とコードペダントリの削減（コードは少ない文字数でポイントに到達します）
• Intellisenseは、コンテキスト上意味のある結果を提供します（拡張メソッドは正しいタイプでのみ表示されます。静的クラスはどこでも使用できます）。

ただし、特筆すべき点は次のとおりです。

• 拡張メソッドは、メソッドチェーンのコーディングスタイルを可能にします。これは、よりバニラなメソッドのラッピング構文とは対照的に、最近人気が高まっています。同様の構文設定は、LINQのメソッド構文で見ることができます。
• メソッドチェーンはクラスメソッドを使用しても実行できますが、これは静的メソッドにはまったく当てはまらないことに注意してください。拡張メソッドは、通常、クラスメソッドではなく静的メソッドであるはずのものに基づいています。

慣習を具体化するのに十分な時間はなかったと私はFlaterに同意しますが、.NET Frameworkクラスライブラリ自体の例はあります。LINQメソッドが.NETに追加されたとき、それらはに直接追加されたのIEnumerableではなく、拡張メソッドとして追加されたことを考慮してください。

これから何が取れますか？LINQは

1. 常に必要とは限らない機能のまとまりのセット、
2. メソッドチェーンスタイルで使用することを目的としています（例：のA.B().C()代わりにC(B(A))）。
3. オブジェクトのプライベート状態へのアクセスを必要としません

これら3つの機能をすべて備えている場合、拡張メソッドは非常に理にかなっています。実際、メソッドのセットに機能＃3と最初の2つの機能のいずれかがある場合、それらを拡張メソッドにすることを検討する必要があると私は主張します。

拡張メソッド：

1. クラスのコアAPIを汚染しないようにする
2. メソッドチェーンスタイルを許可するだけでなく、null値から呼び出された拡張メソッドが最初の引数としてnullを受け取るだけなので、値をより柔軟に処理できるようになりnullます。
3. アクセスすべきではないメソッドで、プライベート/保護された状態に誤ってアクセス/変更しないようにします。

拡張メソッドにはもう1つの利点があります。それでも、静的メソッドとして使用でき、値として直接高次関数に渡すことができます。したがってMyMethod、拡張メソッドの場合、たとえばの代わりに、myList.Select(x => x.MyMethod())単にを使用できますmyList.Select(MyMethod)。私はもっ​​といいと思います。

拡張メソッドの原動力は、シールされているか別のアセンブリにあるかに関係なく、特定のタイプのすべてのクラスまたはインターフェースに必要な機能を追加できることです。これの証拠はLINQコードで確認できますIEnumerable<T>。リストやスタックなど、すべてのオブジェクトに関数を追加します。独自の関数を思いついた場合に、IEnumerable<T>LINQを自動的に使用できるように、関数の将来の証明を目的としています。

とは言っても、言語機能は十分に新しいため、いつ使用するか使用しないかについてのガイドラインはありません。ただし、以前は不可能であった多くのことが可能になります。

• Fluent API（Fluent APIをほぼすべてのオブジェクトに追加する方法の例については、Fluentアサーションを参照）
• 機能の統合（NetCore Asp.NET MVCは拡張メソッドを使用して、起動コードの依存関係と機能を結び付けます）
• 機能の影響のローカライズ（冒頭のステートメントの例）

公平を期すために、時間だけが遠すぎるか、またはどの時点で拡張メソッドが恩恵ではなく障害になるかを知ることができます。別の答えで述べたように、静的メソッドでは実行できない拡張メソッドには何もありません。ただし、慎重に使用すると、コードが読みやすくなります。

同じアセンブリで拡張メソッドを意図的に使用するのはどうですか？

コア機能を十分にテストおよび信頼して、絶対に必要になるまでそれをいじらないことには価値があると思います。これに依存する新しいコードが、新しいコードのメリットのためだけに機能を提供する必要がある場合、拡張メソッドを使用して新しいコードをサポートする機能を追加できます。これらの関数は新しいコードにのみ関係し、拡張メソッドのスコープはそれらが宣言されている名前空間に限定されます。

拡張メソッドの使用を盲目的に除外するつもりはありませんが、十分にテストされた既存のコアコードに新しい機能を本当に追加する必要があるかどうかを検討します。

拡張メソッドを使用するときに確立されたパターンまたはベストプラクティスはありますか？

拡張メソッドを使用する最も一般的な理由の1つは、インターフェースを「変更するのではなく拡張する」手段としてです。むしろ持っているよりもIFoo及びIFoo2、ここで後者を導入新しい方法Bar、Barに追加されるIFoo拡張メソッドを介し。

LINQのは、のための拡張メソッドを使用する理由の一つWhere、Selectなどは、ユーザーがその後、あまりにもLINQクエリの構文で使用されているこれらのメソッドの独自のバージョンを定義することを可能にするためにあります。

それを超えて、私が使用するアプローチは、少なくとも.NETフレームワークで一般的に見られるものに適合しているようです。

1. クラスに直接関連するメソッドをクラス自体の中に置く、
2. クラスのコア機能に関連しないすべてのメソッドを拡張メソッドに配置します。

私が持っているのであればOption<T>、私のようなもの置くところHasValue、Value、==型自体の内部などを。しかし、のようなものMapからモナドを変換する関数、T1にはT2、私は、拡張メソッドに入れたいです：

public static Option<TOutput> Map<TInput, TOutput>(this Option<TInput> input, 
                                                   Func<TInput, TOutput> f) => ...