C# で拡張メソッドを書く方法

拡張メソッドは、C#やオブジェクト指向プログラミング（OOP）の基本的な部分です。C#の拡張メソッドは、既存のクラス、インターフェース、または構造体などの型を修正せずに「拡張」することを可能にします。

これは、サードパーティのライブラリや組み込み.NETの型（例：string、List<T>など）のように所有していない、または変更できない型に新しい機能を追加したい場合に特に便利です。

この記事では、クラスに拡張メソッドを追加する方法、およびサードパーティやシステムクラスに拡張メソッドを追加する方法について学びます。

DateTime拡張メソッドの作成方法
同じ型の拡張メソッドをチェーンする方法
なぜこれらのメソッドをクラスに追加できないのですか？
拡張機能を使用するタイミング
拡張メソッドを使用しないタイミング
拡張機能の設計時に考慮すべき事項
結論

日時拡張メソッドの作成方法

既存のDateTimeクラスと共に使用できるいくつかのメソッドが欲しいとしましょう。たとえば、与えられたDateTimeオブジェクトが週末かどうかを返すメソッドなどです。

拡張メソッドは、基本的には既存の型に対してインスタンスメソッドのように静的メソッドを呼び出すことを可能にする構文糖ですので、静的クラスに定義する必要があります。

拡張メソッドは静的クラスにある必要があります。

オブジェクトは不要: 拡張メソッドを使用するためにオブジェクトを作成する必要はありません。このメソッドは既存の型（stringのような）に新しい機能を追加するため、クラスのインスタンスを必要とせずに動作します。
整理されたコード: 拡張メソッドを静的クラスに配置することで、コードが整理されます。関連するメソッドをグループ化でき、適切な名前空間を使用することで簡単にコードに含めることができます。

したがって、静的クラスを使用することで、元のコードを変更せずに既存の型に便利なメソッドを追加でき、呼び出すためにオブジェクトは必要ありません。

まず、DateTimeExtensionsという静的クラスを作成しましょう。

public static class DateTimeExtensions {

}

これには、作成したいすべてのDateTime拡張が含まれます。

public static bool IsWeekend(this DateTime date)
{
    return date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

説明:

public static bool IsWeekend: これは、IsWeekendという名前の静的メソッドを定義し、bool値（true/false）を返します。

this DateTime date: メソッド引数としてのthisキーワードは、このメソッドが拡張メソッドであることを示します。これは、そのメソッドがDateTimeクラスの拡張となることを意味します。

同じ型の拡張メソッドをチェーンする方法

他のメソッドとチェーンするためには、拡張メソッドは通常、拡張する型と同じ型（または互換性のある型）を返す必要があります。これにより、前のメソッドの結果に対して別のメソッドを呼び出すことができます。

using System.Globalization;

public static string ToTitleCase(this string str)
{
    return CultureInfo.CurrentCulture.TextInfo.ToTitleCase(str.ToLower());
}

public static string TrimAndAppend(this string str, string toAppend)
{
    return str.Trim() + toAppend;
}

上記の例では、ToTitleCaseメソッドとTrimAndAppendメソッドの両方が文字列値を返すため、以下のように拡張メソッドをチェーンすることができます。これにより、文字列をタイトルケースに変換してから、すべての空白をトリミングして指定された文字列を追加します。

TrimAndAppendメソッドには2番目のパラメーターのみが指定されていることに注意してください。最初のパラメーターは、拡張メソッドが適用される文字列であり、前述のようにthisキーワードで示されています。

var title = "hello world   "
    .ToTitleCase()
    .TrimAndAppend("!!");

//出力:
// Hello World!!

拡張メソッドが元の型と異なる型（または互換性のある型）を返す場合、それをチェーンすることはできません。たとえば:

var date = new DateTime();
date.IsWeekend().AddDays(1);

より明確な理由のため、これは機能しません。メソッドをチェーンするときは、それらが元の変数からではなく、前のメソッド呼び出しの戻り値からチェーンされることになります。

ここでは、IsWeekend() というブール値を返す日付があります。その後、存在しない DateTime 拡張機能であるブール値に AddDays(1) を呼び出そうとしました。コードコンパイラはビルドに失敗し、このことを通知するエラーが発生します。

チェーンにインスタンスを返す方法

依存性注入などの設定用の拡張メソッドでは、メソッドチェーンを可能にするために同じインスタンスを返します。これにより、複数の呼び出しで元のオブジェクトやその変更された状態で作業を継続できるため、流暢なインターフェースを実現できます。

車のリストの例を見てみましょう。

public static List<T> RemoveDuplicates<T>(this List<T> list)
{
    // 重複を削除してリストを更新
    list = list.Distinct().ToList();

    // メソッドチェーンを可能にするために変更されたリストを返す
    return list;
}

public static List<T> AddRangeOfItems<T>(this List<T> list, IEnumerable<T> items)
{
    // アイテムの範囲をリストに追加
    list.AddRange(items);

    // メソッドチェーンを可能にするために変更されたリストを返す
    return list;  
}

これらの拡張メソッドからリストを返したので、同じリストに追加のメソッドをチェーンすることができます。例えば、RemoveDuplicates() で重複を削除した後、同じリストで直ちに AddRangeOfItems() を呼び出すことができます。

したがって、次のようなことができます:

var existingStock = new List<string> { "Ford", "Jaguar", "Ferrari", "Ford", "Renault" };

var availableBrands = existingStock
    .RemoveDuplicates()
    .AddRangeOfItems(new[] { "Lamborghini" }); // 新しい在庫が利用可能

Console.WriteLine("Brands Available Now: " + string.Join(", ", availableBrands));

// 出力: Brands Available Now: Ford, Jaguar, Ferrari, Renault, Lamborghini

重複を車のブランドのリストから削除し、同じリストに新しい在庫を追加しました。これは、RemoveDuplicatesがリストを返すため、AddRangeOfItemsとチェーンできるからです。

RemoveDuplicatesがリストの代わりにvoidを返していた場合、メソッドをチェーンすることはできませんでした。それでも重複は削除されますが、新しい在庫を追加するなどのさらなるアクションは、同じ式で行うことはできません。

RemoveDuplicatesを更新してリスト引数を更新する必要もありました。Distinct()は新しいリストを返し、以下のように返されていないため、これははるかに冗長であることに同意していただけると思います。

public static void RemoveDuplicates<T>(this List<T> list)
{
    // 一意の要素を取得し、元のリストをクリア
    var distinctItems = list.Distinct().ToList();
    list.Clear(); 

    // 一意のアイテムを元のリストに戻す
    list.AddRange(distinctItems);
}

なぜこれらのメソッドをクラスに追加できないのですか？

メソッドがクラスの機能のコア部分でない場合、拡張メソッドに配置することで、クラスを集中させ、保守しやすくすることができます。

関心の分離：拡張メソッドを使用すると、コードがクリーンになり、複雑さを減らすのに役立ちます. よく使用されないメソッドでクラスが膨れ上がるのを避けるのに役立ちます。

外部ライブラリの強化：ソースコードを変更できないライブラリやフレームワークを使用している場合、拡張メソッドを使用すると、それらの定義を変更せずに機能を追加できます。

ファイルを扱うためにSystem.IO名前空間のFileInfoクラスを使用しているとしましょう。ファイルが大きすぎるかどうかを簡単にチェックするメソッドを追加したいかもしれません（例えば、1 GB以上）。しかし、FileInfoクラスはSystem.IO名前空間に属しているため（つまり、.Netに組み込まれているため）、直接変更することはできません。

拡張なし：

var fileInfo = new FileInfo("myFile.txt");

if (fileInfo.Length > 1024 * 1024 * 1024) // ファイルサイズが1GBを超えている
{
    Console.WriteLine("The file is too large.");
}
else
{
    Console.WriteLine("The file size is acceptable.");
}

拡張メソッドを使用：

ファイルが1 GBより大きいかどうかをチェックする拡張メソッドを追加することで、再利用性を高めることができます。

public static class FileInfoExtensions
{
    //拡張メソッド、デフォルトのファイルサイズは1GB（上書き可能）
    public static bool IsFileTooLarge(this FileInfo fileInfo, long sizeInBytes = 1024 * 1024 * 1024)
    {
        return fileInfo.Length > sizeInBytes;
    }
}

これで、FileInfoオブジェクトに直接IsFileTooLargeメソッドを使用でき、コードがよりクリーンになります：

csharpCopy codevar fileInfo = new FileInfo("myFile.txt");

if (fileInfo.IsFileTooLarge())
{
    Console.WriteLine("The file is too large.");
}
else
{
    Console.WriteLine("The file size is acceptable.");
}

サードパーティのライブラリやパッケージを拡張することで、コードの互換性が大幅に向上します。

より良い整理と可読性：機能やコンテキストに基づいて拡張メソッドを静的クラスに整理することで、見つけやすく使用しやすくなります。これは、拡張メソッドのチェーンを許可することで確実に強化されます。

拡張を使用するタイミング

ユーティリティメソッドの場合： 型にとって便利なユーティリティメソッドがあるが、その型自体には直接属さない場合（例えば、フォーマット、バリデーション）。
組み込み型の拡張の場合: 組み込み型（stringやDateTimeなど）に機能を追加したいが、それらを修正したくない場合。
メソッドをオプションにしたい場合: ユーザーがメインクラスの設計に組み込むことを強制せずに、利用可能な追加メソッドを提供したい場合。

例のシナリオ

Person クラスがあり、人物の名前をきれいにフォーマットするメソッドを追加したいと想像してください:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

// 静的クラス内の拡張メソッド
public static class PersonExtensions
{
    public static string GetFullName(this Person person)
    {
        return $"{person.FirstName} {person.LastName}";
    }
}

GetFullName の拡張メソッドを使用することで、Person クラスをそのコアな責任に集中させつつ、有用な機能を提供することができます。

拡張メソッドを使用しない場合

コア機能の場合: メソッドがクラスのコアな動作にとって不可欠である場合、それはクラス自身の一部であるべきで、拡張ではありません。
タイトな連携のため：拡張メソッドがクラスの非公開状態を詳しく知る必要があるか、内部ロジックに定期的にアクセスする必要がある場合。
公開APIのため：公開向けのライブラリやAPIを設計する際、ユーザーに必要なメソッドをクラスに直接含めることが、拡張メソッドを見つけたり作成したりすることよりも良い場合があります。

拡張機能を設計する際の考慮事項

拡張メソッドは多くのケースで強力で便利ですが、使用する際に最適でない場合や特定の欠点がある場合があります：

隠れた動作/混乱

拡張メソッドはクラス定義に直接表示されないため、利用可能な拡張が不慣れな開発者によって見つけにくい場合があります。
開発者は、これらの拡張メソッドが存在することを知っておく必要があります。そうでないと、IntelliSenseなどの機能を備えたIDEで作業していない限り（たとえば、Visual Studio、JetBrains Riderなど）、それらを使用することを見逃すかもしれません。これらのIDEは、適切な型を検出すると他のファイルや名前空間から拡張メソッドを提案することができます。機能豊富なIDEがない場合、開発者は拡張メソッドを認識するか、それらが保存されているフォルダを見つける必要があります。

プライベートメンバーにアクセスできない

拡張メソッドは、publicまたはinternalのメンバー（メソッド、プロパティ、フィールド）のみにアクセスできます。
拡張メソッドは、外部からクラスの一部であるかのように動作するため、クラスのprivateまたはprotectedメンバーにアクセスできません。これは、クラスの外部からの通常のメソッド呼び出しと類似しています。

例:

public class Car
{
    private string engineNumber = "12345"; // プライベートフィールド

    public string Brand { get; set; } = "Ford"; // パブリックプロパティ

    private void StartEngine() // プライベートメソッド
    {
        Console.WriteLine("Engine started");
    }
}

public static class CarExtensions
{
    public static void DisplayBrand(this Car car)
    {
        Console.WriteLine($"Brand: {car.Brand}"); // パブリックな「Brand」プロパティへのアクセス
    }

    public static void TryAccessPrivateField(this Car car)
    {
        // プライベートな「engineNumber」にはアクセスできない
        // これによりコンパイル時エラーが発生します。
        Console.WriteLine(car.engineNumber);
    }
}

コードの重複と過剰使用

場合によっては、拡張メソッドがコードの重複を促すことがあります。複数のプロジェクトやクラスが同様の拡張メソッドを必要とする場合、異なる場所で同じ拡張メソッドを書いたりコピーしたりすることになり、コードを一貫して管理および更新することが難しくなります。

これを避けるために、コードを効果的に整理してください。すべての拡張を拡張フォルダーやプロジェクト内に、オリジンに近い場所に保持することをお勧めします（アプリケーション内で使用されているデザインパターンに依存します）。

拡張の乱用：過度に使用されると、グローバル空間に不必要なメソッドが散乱する可能性があります。これにより、型のAPIが汚染され、クラスのコア機能と拡張メソッドによって追加された機能の理解が難しくなることがあります。

場合によっては、拡張メソッドを使用するのではなく、別のヘルパークラスやサービスに機能をカプセル化する方が良いでしょう。

結論

拡張メソッドは、クリーンでモジュラーな方法で機能を追加するのに便利ですが、混乱や名前空間の競合、プライベートメンバーへのアクセス不足を引き起こす可能性もあります。

この記事全体で強調されているように、拡張メソッドには多くの用途があり、効果的に使用される場合、Dotnetフレームワークの非常に素晴らしい機能です。適切な場合に使用すべきですが、クラス自体に属する機能の代替として使用するべきではありません。

目次