C# 拡張メソッドの使い方 — 作り方と実務3パターン（既存型を汚さず .Xxx() を足す）

みなさんこんにちは！ヒロポンです！

業務系のコードを触ってると、こんな Utility クラス、見覚えないですか？？

var name = StringUtil.TrimFull(row["name"]);
var dept = StringUtil.OrDefault(StringUtil.TrimFull(row["dept"]), "(未設定)");

自作のヘルパーメソッドを static クラスにひたすら溜めてって、呼び出しが Utility.Trim(x) StringUtil.Xxx(x) だらけ。動くんですよ。動くんですけど、正直ちょっと読みにくい。

これ、x.Trim() みたいに メソッドを型に生やす 書き方に整理できます。それが拡張メソッド。

今回は「C# 拡張メソッドの使い方」を、作り方から実務の3パターンまで、コピペで動くコードで一気にいきます。

結論: 拡張メソッドは「this を付けた static メソッド」で既存型に .Xxx() を生やす仕組み

先に答えです。拡張メソッドは、static メソッドの 第一引数の頭に this を付けるだけ で作れます。

public static class StringExtensions
{
    // this を付けた第一引数の型 (string) に、このメソッドが生える
    public static bool IsBlank(this string? s) => string.IsNullOrWhiteSpace(s);
}

これで string に IsBlank() が生えます。呼び方はこう。

string name = "  ";
Console.WriteLine(name.IsBlank());          // True
Console.WriteLine("営業部".IsBlank());       // False
// StringUtil.IsBlank(name) じゃなく name.IsBlank() で呼べる！！

実行結果:

Utility.IsBlank(name) が name.IsBlank() になりました。たったこれだけ。既存の string 型のソースには一切手を入れてません。

ここで「なるほど、あとは応用か」と分かった人は、このタイミングでページを閉じてもらってもかまいません！ 以下は3つの実務パターンと、業務SEが最初に踏むハマりポイントの話です。

そもそも拡張メソッドは何がうれしいのか

一言で言うと、自分で編集できない型に、後からメソッドを足せる のがうれしいポイントです。

string や DateTime、ADO.NET の DataRow。この辺は .NET が持ってる型。私たちがソースをいじって新しいメソッドを追加、なんてできません。

じゃあ従来どうしてたか。さっきの StringUtil.TrimFull(x) みたいな static ヘルパーですね。これも動くんですけど、呼び出しがネストすると途端に読みにくい。A(B(C(x))) みたいになるやつです。

拡張メソッドなら x.C().B().A() と 左から右に読める 形になる。処理の流れが素直に追えます。

ん？ これ普通にインスタンスメソッドっぽく見えるけど、中身は static じゃないの？ と思った人、鋭いです。実は正体は完全に static メソッドで、コンパイラが name.IsBlank() を StringExtensions.IsBlank(name) に翻訳してるだけなんですよね。見た目がインスタンスメソッド、中身は static。この二重性だけ頭の隅に置いといてください。

使いどころ その1: 既存の string / DataRow に業務用の便利メソッドを足す

一番よく使うのがこれ。現場で何度も書く小さな処理を、型に生やして使い回します。

public static class BusinessStringExtensions
{
    // 半角も全角スペースもまとめてトリム (業務データあるある)
    public static string TrimFull(this string? s)
        => (s ?? "").Trim().Trim('　');

    // 空なら既定値に差し替える (DB の未入力を表示用に整える)
    public static string OrDefault(this string? s, string fallback)
        => string.IsNullOrEmpty(s) ? fallback : s;
}

使うとこんな感じ。

string dept = "　営業部　";               // 前後に全角スペース
Console.WriteLine(dept.TrimFull());        // 営業部
Console.WriteLine("".OrDefault("(未設定)")); // (未設定)

実行結果:

TrimFull() は、半角の Trim() だけだと取り切れない全角スペースまで落とします。業務データって全角スペース混じりが本当に多い。だからこれ1個あるだけで地味に助かります。

寄せるべきは、こういう 「その型に対する横断的な処理」。特定の画面や特定の業務ロジックじゃなく、「string 全般に効く便利機能」を足すイメージですね。

使いどころ その2: LINQ 風のメソッドチェーンを自作する

普段使ってる Where や Select、あれ全部 IEnumerable<T> に対する拡張メソッドなんですよ。LINQ の正体は拡張メソッドの塊、というわけです。

ということは、同じノリで 自分専用のチェーンメソッド も作れます。

public static class EnumerableExtensions
{
    // null を除いて返す (ゆるい業務リストをきれいにする)
    public static IEnumerable<T> WhereNotNull<T>(this IEnumerable<T?> src)
        where T : class
        => src.Where(x => x is not null)!;

    // 指定件数ずつのページに切る
    public static IEnumerable<List<T>> Paged<T>(this IEnumerable<T> src, int size)
    {
        var buf = new List<T>(size);
        foreach (var x in src)
        {
            buf.Add(x);
            if (buf.Count == size) { yield return buf; buf = new List<T>(size); }
        }
        if (buf.Count > 0) yield return buf;
    }
}

呼び出し側はこう。

var names = new string?[] { "田中", null, "佐藤", null, "鈴木" };
var clean = names.WhereNotNull().ToList();
Console.WriteLine(string.Join(",", clean));   // 田中,佐藤,鈴木

foreach (var page in Enumerable.Range(1, 5).Paged(2))
    Console.WriteLine(string.Join("-", page.Select(x => x.ToString())));
// 1-2
// 3-4
// 5

実行結果:

WhereNotNull() は標準の Where と自然につながります。src.WhereNotNull().Select(...) みたいに、既存 LINQ と混ぜて使えるのが良い感じ！！

Paged() のほうは、1万件を1000件ずつ処理したい、みたいなバッチでよく出るやつ。標準の Chunk（.NET 6 以降）に近いんですが、戻り値の型や挙動を現場に合わせて自作できる。ここが拡張メソッドの強みですね。

使いどころ その3: null / DBNull を安全に扱うヘルパーにする

業務SEにとって一番の鬼門、ADO.NET の DBNull。これも拡張メソッドで安全に畳めます。

using System.Data;

public static class DataRowExtensions
{
    // DBNull を空文字にして安全に取り出す
    public static string GetStr(this DataRow row, string col)
        => row[col] is DBNull ? "" : Convert.ToString(row[col]) ?? "";

    // DBNull なら null 許容 int に
    public static int? GetIntOrNull(this DataRow row, string col)
        => row[col] is DBNull ? null : Convert.ToInt32(row[col]);
}

DataTable から取り出す時、いちいち row["name"] is DBNull ? ... を書かなくて済みます。使うとこんな感じ。

var dt = new DataTable();
dt.Columns.Add("name", typeof(string));
dt.Columns.Add("age", typeof(int));
dt.Rows.Add("田中", 40);
dt.Rows.Add(DBNull.Value, DBNull.Value);   // 未入力の行

foreach (DataRow r in dt.Rows)
{
    var name = r.GetStr("name").OrDefault("(名前なし)");  // その1 の OrDefault と連結！
    var age  = r.GetIntOrNull("age")?.ToString() ?? "-";
    Console.WriteLine($"{name} / {age}");
}
// 田中 / 40
// (名前なし) / -

実行結果:

注目してほしいのが r.GetStr("name").OrDefault("(名前なし)") のとこ。その1で作った OrDefault とチェーンでつながってます。 拡張メソッド同士を数珠つなぎにできるので、DBNull の分岐を本文からきれいに追い出せる。

DBNull を三項演算子で毎回書くのが面倒な話は C#でDBNullチェック時にエラーを出さずにキャストする最適解 でも触れてますが、拡張メソッドに寄せると呼び出し側がもっとスッキリします。

いつ拡張メソッドにすべきか（判断の早見表）

「なんでもかんでも拡張メソッドにすればいいの？？」というと、そうでもないです。static ヘルパーのままが正解のケースもある。ざっくり判断軸を表にしました。

通して見ると分かるんですが、拡張メソッドが圧倒的に強いのは 「自分で編集できない既存型に、横断的な便利機能を足したい」 の一点だけ。逆に、定義の追いやすさでは負けます。自作クラスの本質メソッドなら、素直にクラス本体に書いた方がいい。

「既存型か、自作型か」「横断的な補助か、その型の本質か」。この2軸で選ぶと、だいたい外しません。

ハマりポイント: 知らないと定義を追えなくなる3つ

拡張メソッドは便利なんですけど、業務SEが最初に踏みがちな罠が3つあります。全部知っておけば1個も踏まずに済みます。

① 同名のインスタンスメソッドがあると、そっちが優先される

拡張メソッドとインスタンスメソッドが同じシグネチャで衝突すると、常にインスタンスメソッドが勝ちます。 拡張メソッドは「他に候補がない時だけ」呼ばれる、後出しジャンケンの負け側なんですよね。

public static class Ext
{
    // string には元から ToString() がある
    public static string ToString(this string s) => $"[{s}]";
}

// 呼ぶと…
Console.WriteLine("abc".ToString());  // abc ← Ext.ToString は呼ばれない！

実行結果:

[abc] を期待して書いても、返るのは abc。標準の ToString() が優先されて、拡張メソッドは黙って無視されます。エラーも出ないから気付きにくい。これで小一時間溶かした記憶があります……。既存メソッドと名前がかぶらないように寄せるのが安全です。

② using で名前空間を通さないと、そもそも見えない

拡張メソッドは、定義した static クラスの 名前空間を using で通してないと、インテリセンスにすら出てきません。

// StringExtensions が MyApp.Extensions 名前空間にある場合
using MyApp.Extensions;   // ← これが無いと name.IsBlank() が使えない

string name = " ";
bool b = name.IsBlank();