1. 概要（Overview）
Remove Middle Man は、クラスが単に他のクラスへの呼び出しを 委譲するだけ になっている場合に、その仲介を取り除き、クライアントが直接呼び出すようにするリファクタリングです。
目的は以下の通りです：
- 不要なレイヤーを削除してコードをシンプルにする
- クラスの責務を明確にし、API の冗長化を防ぐ
- 過度なカプセル化や「形式的な仲介」を解消する
2. 適用シーン（When to Use）
- クラスの多くのメソッドが、単に委譲しているだけ
- クラスにほとんどビジネスロジックがない
- Hide Delegate を過剰に使った結果、窓口メソッドが肥大化している
- クライアントが「直接呼び出した方がシンプル」になる
よくある匂い：
- Middle Man（仲介人）
- Needless Indirection（不要な間接化）
3. 手順（Mechanics / Steps）
- 仲介人クラスの委譲メソッドを確認
- クライアントが直接呼び出せるように、委譲先を公開する（getter 提供など）
- クライアントコードを修正して委譲先を直接呼び出す
- 仲介メソッドを削除
4. Kotlin 例（Before → After）
Before：仲介するだけのクラス
class Department(private val manager: Person) {
fun getManagerName(): String = manager.name
}
class Person(val name: String)
fun printManager(department: Department) {
println(department.getManagerName()) // Department が仲介するだけ
}
-
DepartmentはPerson.nameを返すだけの「仲介人」になっている
After：仲介を削除
class Department(val manager: Person) // 直接公開
class Person(val name: String)
fun printManager(department: Department) {
println(department.manager.name) // ✅ 直接呼び出し
}
→ クライアントが manager に直接アクセスするように変更。
→ 冗長な仲介が消え、コードがシンプルに。
5. 効果（Benefits）
- 不要な委譲を削除して、コードが簡潔に
- クラスの API がスリムになり、責務が明確化
- クライアントとデータ構造の関係が直感的になる
6. 注意点（Pitfalls）
- 内部構造を 外部に晒しすぎるとカプセル化が弱まる
- 直接参照させることで、変更の影響範囲が広がる可能性がある
-
Hide Delegate と Remove Middle Man のバランスが重要
- 内部構造が頻繁に変わるなら「Hide Delegate」
- 安定しているなら「Remove Middle Man」
まとめ
- Remove Middle Man は「委譲するだけの仲介人を削除する」リファクタリング
- 判断基準：その仲介は本当に意味があるか？
- 基本思想：過剰な間接化を排除して、設計をシンプルに保つ