ラムダ式の利点と欠点 =>

1. ラムダ式の利点

プログラミングでは似たような作業がよく出てくるよね。例えば：「ユーザーのリストから18歳以上をフィルタする」、「条件を満たす数の合計を求める」、「商品の価格でソートする」。ラムダがなければ、こういう処理ごとに別メソッドを作ることになって、コードが煩雑になりがち。ラムダを使うとコードがコンパクトになり、考えたことをそのまま表現しやすくなるんだ。

ラムダ式は多くのモダンな言語（C#に限らない）で標準的な手法で、フィルタやハンドラ、変換関数など「振る舞いを値として渡す」ことを簡単にしてくれるよ。

1. 簡潔さと明快さ

ラムダ式は、余分なメソッド宣言や冗長な匿名デリゲートを書かずに済ませられる。ちょっとした処理をその場で書けるのが便利。例えば、ラムダ登場前の数値リストフィルタはこんな感じだった：

List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6 };

// ラムダが登場する前:
List<int> evenNumbers = numbers.FindAll(delegate(int x) { return x % 2 == 0; });

// ラムダ式を使うと:
List<int> evenNumbers2 = numbers.FindAll(x => x % 2 == 0);

結果は同じだけど、ラムダを使うとずっと簡潔になる。大きなプロジェクトでは行数の節約が効いてくるよ。

2. 可読性と表現力の向上

ラムダは処理の本質に集中させてくれて、冗長な構文ノイズを減らしてくれる。コードが自然言語に近くなるよ：

var adults = users.Where(user => user.Age >= 18);

これを別メソッド bool IsAdult(User user) として用意するのと比べてみて。フィルタのためだけにメソッドを書くのは無駄に感じることがあるよね。

3. LINQやコレクションAPIとの相性が良い

ラムダの強みはLINQやコレクションと組み合わせたときに発揮される。多くのコレクションメソッドやLINQオペレータは関数を引数に取る（例：フィルタには Func<T, bool>）。ラムダならその場で必要な関数を定義できる：

var expensive = products.Where(p => p.Price > 1000);
var firstBook = books.FirstOrDefault(b => b.Title.StartsWith("C#"));
var doubled = numbers.Select(n => n * 2);

4. 外側のスコープの変数をキャプチャできる（クロージャ）

ラムダ式は外側で宣言された変数を使える。これで柔軟なオンザフライ関数を作れる：

int minAge = 18;
var filtered = users.Where(u => u.Age >= minAge); // minAge はラムダに「キャプチャ」されている

これは「パラメータ調整された関数」を動的に作るパターンで便利だよ。

面白いこと：ラムダの内部で外側の変数を読むだけでなく、場合によっては変更することもできる。とはいえこれは注意が必要 — クロージャに関する講義で詳しくやるよ！

5. 埋め込みでコンテキストに近いコード

ラムダは使われる場所にそのまま書けるので、プロジェクト内のどこかに散らばったメソッドを探さなくて済む。情報が凝縮されていて扱いやすい。

この講義で扱っている小さな図書館の本管理システムの例で、以下のような本のリストがあったとしよう：

public class Book
{
    public string Title { get; set; }
    public string Author { get; set; }
    public int Year { get; set; }
    public double Price { get; set; }
}

// どこかのコード:
List<Book> books = new List<Book>
{
    new Book { Title = "C# 9.0 in a Nutshell", Author = "Skeet", Year = 2022, Price = 350 },
    new Book { Title = "CLR via C#", Author = "Richter", Year = 2019, Price = 250 },
    // ...
};

// 価格が300より高い本を探す:
var expensiveBooks = books.Where(b => b.Price > 300).ToList();

選択条件が呼び出しの近くに書かれているので、別の関数を探す手間が省けるよ。

6. コールバック、イベント、タイマーでの利用

ラムダはワンオフの処理を設定するのに向いている。例えばイベントハンドラ（コールバック）：

button.Click += (sender, args) => Console.WriteLine("ボタンが押された！");

処理がシンプルな場合、別メソッドをわざわざ書く必要がなくなる。

7. デリゲートの表現力を広げる

以前は振る舞いを渡すには名前付きメソッドを用意する必要があったけど、今はその場で関数を書ける：

Timer timer = new Timer(_ => Console.WriteLine("Tick!"), null, 0, 1000);

8. テストやDIで便利

ラムダを使えばテスト用に振る舞いを差し替えやすい。コンストラクタがデリゲートを受け取る設計なら、テスト時に必要な振る舞いのラムダを渡してモックを作れる。わざわざユーティリティクラスや一時クラスを用意しなくていいことが多いよ。

2. ラムダ式の主な欠点

強力な道具には欠点もある。ここではラムダが引き起こす可能性のある問題点を見ていこう。

1. 深いネストで可読性が落ちる

ラムダは便利だけど、一箇所にたくさん書くと読みにくくなる。ネストしたラムダや長いラムダは解析が面倒になる：

var result = items.Select(x => x.Children.Where(y => y.Value > 10)
                         .Select(z => z.Name.ToUpper())
                         .ToList());

もう少しレベルが増えると、一気に「コード読む脳トレ」になってしまうよ。

ヒント：ラムダが3〜4行より長くなったら、名前付きメソッドに切り出すのがおすすめ。流行の短縮より可読性を優先して大丈夫。

2. デバッグの難しさ

特にLINQチェーンの中に1行で書いたラムダはデバッガとの相性が良くないことがある。ラムダ内部にブレークポイントを置いたり、途中の値を確認するのが難しい場合があるんだ。

デバッグしやすくするために、一時的にラムダの本体を名前付きメソッドに移したり、長いLINQチェーンを途中変数で分割するといいよ。

3. 引数や戻り値の型が分かりにくいことがある

ラムダは通常デリゲート（Func<...>, Action<...>, Predicate<T>）として渡される。genericなメソッドなどでは、引数や戻り値の型がすぐに分かりづらいことがある。

例えば：

Func<int, string, double> myFunc = (a, b) => a + b.Length; // あれ？戻り値はintになっちゃう、でも期待はdouble

コンパイラはエラーを出すけど、初心者だと「型が合わない」原因を突き止めるのに時間がかかることがあるよ。

4. 変数キャプチャのトラブル

外側の変数をキャプチャするクロージャは便利だけど扱いを間違えると期待しない結果になる。例えばループ内で：

var actions = new List<Action>();
for (int i = 0; i < 3; i++)
{
    actions.Add(() => Console.WriteLine(i));
}
foreach (var action in actions) action();

多くの人は 0 1 2 を期待するけど、実際には 3 3 3 が出ることがある。なぜなら、ラムダは変数そのものをキャプチャしていて、実行時には i が既に 3 になっているからだよ。

これは初心者にありがちな間違いで、詳しくは 公式ドキュメント を参照してね。対処法はあるけど注意が必要。

5. 名前がないことで再利用時に困ることがある

ラムダはワンオフ向け。もし同じ条件や関数を複数箇所で使うなら、名前付きメソッドにしたほうがいい。でないと重複や修正時のミスが増えるよ。

6. XMLコメントを付けられない不便さ

ラムダにはXMLドキュメントコメントを付けられない（自動生成されるドキュメント用に）。ラムダに説明が必要なら、コード内に通常のコメントを書くしかない。

7. パフォーマンス上の注意点

ほとんどのケースでラムダは問題にならないけど、外側の変数をキャプチャするラムダを大量に作るとクロージャ用のオブジェクトが割り当てられてパフォーマンスに影響することがある。tight loopや高負荷サービスなどでは、staticメソッドなどの方が安い場合があるので考慮してね。

8. goto、break、continue の制約

ラムダがループ内で宣言されている場合でも、ラムダ内部から外側のループに対して直接 break や continue を使うことはできない — 構文上許されていないから気をつけて。

9. ラムダで全ての振る舞いを書けるわけではない

ラムダは属性を付けたりアクセス修飾子を指定したり、特定の特殊な操作（例えば名前付きのローカル関数の宣言など）を行うときには使えないことがある。万能ではないと覚えておこう。

3. トレードオフの判断

ラムダが便利なとき

それでもラムダを避けたほうがいいとき

• ロジックが長く、分岐や計算が多い場合。
• ラムダが読み手にとって不明瞭で説明がない場合。
• 関数にドキュメントが必要、複数箇所で使う、または分かりやすい名前を付けたい場合。
• ラムダが深いネストの中で使われていて可読性を失うリスクがある場合。

4. ラムダでよくあるミス

ループでの変数キャプチャのミス：

List<Action> actions = new List<Action>();
for (int i = 0; i < 5; i++)
{
    actions.Add(() => Console.WriteLine(i));
}
foreach (var act in actions) act(); // 全て5を出力する！

正しいやり方：

for (int i = 0; i < 5; i++)
{
    int captured = i; // 別の変数に値をキャプチャする
    actions.Add(() => Console.WriteLine(captured));
}

長すぎるラムダ：

books.Where(b => b.Price > 1000 && b.Title.Contains("C#") && b.Author.Length > 4 && などなど...);
// コードが読みにくくなったら、メソッドに切り出そう！

ドキュメントが必要な場所でラムダを使っている：
同じ処理を何度も使うか、詳しい説明が必要なら名前付きメソッドを書こう：

bool IsExpensiveBook(Book book) => book.Price > 1000;
books.Where(IsExpensiveBook);