デリゲートの正体と実践ガイド：C# の関数参照から設計パターンとしての委譲、iOS デリゲート設計まで
エバープレイ編集部はじめに — 「デリゲート」とは何か
ITやプログラミングの文脈で「デリゲート（delegate）」という語は複数の意味で用いられます。大きく分けると（1）言語機能としてのデリゲート（特に C# における型安全な関数参照）と、（2）設計パターンとしてのデリゲーション（委譲、オブジェクト間の役割委任）があります。本稿では両者を区別して詳述し、代表的な実装例、利点・欠点、現場での適用上の注意点やベストプラクティスまで幅広く掘り下げます。
言語機能としてのデリゲート（主に C#）
プログラミング言語におけるデリゲートは「関数ポインタの高レベル版」と言えます。代表的なのは .NET（C#）における delegate 型です。delegate はメソッドへの参照（インスタンスメソッドならインスタンスとメソッド、静的メソッドならメソッドそのもの）を型安全に保持・呼び出すことができます。
基本的な特徴
- 型安全：シグネチャ（戻り値と引数の型）が一致している必要がある。
- オブジェクト指向：デリゲートはオブジェクトで、System.Delegate / System.MulticastDelegate を継承する。
- インスタンスメソッド・静的メソッド両方を参照可能。
- マルチキャスト：複数のメソッドを結合（Invoke 時に順次呼ばれる）できる（MulticastDelegate）。
C# の基本例
代表的な宣言と使用例：
public delegate void MyDelegate(int x);
MyDelegate d = new MyDelegate(SomeMethod);
d(10); // 呼び出し
実務ではジェネリックの Action/Func がよく使われます：
Action<int> a = x => Console.WriteLine(x);
a(5);
Func<int,int> f = x => x * x;
int r = f(3); // 9
イベントとの関係
C# では delegate を用いてイベント（event）を実装します。event は delegate の「発行側」が外部から直接 Invoke されないようにアクセスを制限するラッパーです。外部は +=/-= で購読・解除できるが、発火（Invoke）は宣言側でしかできません。
マルチキャストと注意点
- 複数メソッドを一つのデリゲートに結合できる。結合は Delegate.Combine（+=）で行われ、Invoke は登録順に呼び出される。
- 戻り値がある場合は最後に登録された戻り値が返る（戻り値を合成する仕組みはない）。したがって複数戻り値を扱う設計は注意が必要。
- スレッド安全性：イベントを呼ぶ際はローカル変数にコピーして null チェックするパターンが推奨される。なぜなら別スレッドで購読解除され null になりうるから。
言語横断的な「コールバック」としてのデリゲート
言語により呼び名は異なりますが、多くの言語は何らかの形で「関数を値として渡す」仕組みを持っています。C の関数ポインタ、C++ の std::function、Java の関数型インターフェース、JavaScript の関数オブジェクト、Python の第一級関数などです。これらは「デリゲート的」な役割を果たしますが、実装や型安全性は言語ごとに異なります。
設計パターンとしてのデリゲーション（委譲パターン）
デリゲーションはオブジェクト指向設計の一技法で、あるオブジェクトが本来行うべき処理の一部を別のオブジェクトに委ねる（委譲する）ことを指します。GOF（Gang of Four）のパターン群で直接「Delegate」という名のパターンはないものの、委譲の考え方は多くのパターン（Strategy、Adapter、Decorator など）に内包されています。
利点
- 継承の代替：振る舞いを動的に変えたい場合、継承より委譲（コンポジション＋インタフェース）を使うことで柔軟性が上がり、結合度を下げられる。
- 責務分離：各オブジェクトに単一責務を持たせやすく、テストや再利用が容易になる。
- ランタイム変更：デリゲートオブジェクトを切り替えることで振る舞いを動的に変更可能。
欠点・注意点
- 間接呼び出しが増え、トレースがやや複雑になることがある。
- 過度の委譲は設計の複雑化を招く（どこで何が行われるか分かりにくくなる）。
- 循環参照に注意（特に参照保持のルールがある言語、例：Objective‑C/Swift の retain サイクル）。
モバイル（iOS）におけるデリゲートパターン（Objective‑C / Swift）
iOS 開発では「delegate」という用語がそのまま設計パターンとして頻繁に使われます。UIKit の UITableViewDelegate や UITextFieldDelegate などが典型例です。実装は「プロトコル（インターフェース）を定義し、処理を委譲するオブジェクトがそのプロトコルに従う」という形を取ります。
Objective‑C の場合
- プロトコルを定義し、プロパティで delegate を保持する。多くの場合 weak（弱参照）で保持して循環参照を避ける。
Swift の場合（例）
protocol MyDelegate: AnyObject {
func didSomething(_ sender: MyClass)
}
class MyClass {
weak var delegate: MyDelegate?
func doWork() {
// 完了したら通知
delegate?.didSomething(self)
}
}
AnyObject 制約と weak を使うことで retain cycle を避けるのが一般的です。UITableView の delegate/dataSource は weak として保持されます。
実務上のベストプラクティス
- 適切な粒度で委譲する：単一責務の原則（SRP）に従い、担当範囲を明確にする。
- 弱参照（weak）を利用してメモリリークを予防する（言語とランタイムのルールに従う）。
- イベントやコールバックのエラーハンドリングとタイムアウトを設計する。非同期処理ではキャンセルや例外処理が重要。
- 公開 API として delegate を提供する場合、ドキュメントで呼び出し順序やスレッド要件（メインスレッドで呼ぶか等）を明確にする。
- C# ではイベント購読の解除忘れに注意（リークの原因）。イベントを購読した側は適切に -= するか、弱参照イベントライブラリを利用する。
よくある誤解
- 「デリゲート = C# 固有のもの」ではない。用語と概念は広く存在するが、C# の delegate は言語固有の実装例。
- 「デリゲートは常にマルチキャスト」ではない。言語や実装により単一参照しか持てないものもある。
- 「イベントとデリゲートは同じ」ではない。イベントは delegate を使った公開機構で、アクセス制御が付く。
具体的な適用例と比較
典型的な利用場面：
- UI フレームワークでのイベント通知（例：ボタンが押されたら delegate に通知する）。
- 非同期 API のコールバック（完了時に登録した関数を呼ぶ）。
- 戦略パターンの実装（振る舞いを委譲オブジェクトに切り替える）。
- ライブラリのカスタマイズポイント（ユーザーコードに処理のフックを提供）。
まとめ
「デリゲート」は文脈に応じて「関数参照（言語機能）」と「委譲（設計パターン）」の二つの意味で使われます。どちらも「責務の分離」と「柔軟な振る舞いの切り替え」を可能にし、現代的なソフトウェア設計で広く用いられる重要な考え方です。一方で、メモリ管理やスレッド安全性、戻り値・エラーハンドリングの設計など注意点も多いため、言語特性と実行環境を踏まえた設計が求められます。
参考文献
- Microsoft Docs: Delegates (C# Programming Guide)
- Microsoft Docs: Events (C#)
- Wikipedia: Delegate (computer programming)
- Apple Developer Documentation (UIKit, delegates and data sources)
- Refactoring.Guru: Delegation and related design patterns
投稿者プロフィール
