1. 概要（Overview）
Collapse Hierarchy は、
不要に複雑な継承階層を整理し、サブクラスとスーパークラスを統合する リファクタリングです。
- サブクラスが実質的に意味を持たず、ほとんどコードを追加・変更していない場合
- あるいは、スーパークラスが冗長で存在意義が薄い場合
このような場合は階層を簡略化し、単一のクラスに統合した方がシンプル になります。
目的：
- 不要な階層を取り除き、コードを簡潔にする
- クラス階層の可読性・理解しやすさを向上
- 継承関係の誤用によるメンテナンス負荷を軽減
2. 適用シーン（When to Use）
- サブクラスがほとんどコードを追加していない
- スーパークラスが抽象化として意味をなしていない
- クラス間の区別がほぼなく、実質的に冗長 になっている
- 設計初期では必要と思ったが、実装が進んで無用になった階層
よくある匂い：
- Speculative Generality（過剰な一般化）
- Lazy Class（怠け者クラス）
- Unnecessary Hierarchy（不要な階層）
3. 手順（Mechanics / Steps）
- 階層を簡略化できるか確認（責務が重複していないか）
- サブクラス → スーパークラス、あるいはスーパークラス → サブクラスへ統合
- クラス宣言を削除し、クライアントコードを修正
- テストを実行し、動作に問題がないか確認
4. Kotlin 例（Before → After）
Before：意味のない階層
open class Person(
val name: String
)
class Employee(name: String) : Person(name)
-
EmployeeはPersonに何も追加していない - 実質的に
Employeeは「名前しか持たない Person」と同じ存在
After：階層を統合
class Person(
val name: String
)
-
Employeeを削除し、Personだけを残す - 階層が単純化され、理解しやすくなる
5. 効果（Benefits）
- クラス階層をシンプル化
- 可読性・理解しやすさが向上
- 継承構造の維持コスト削減
- 過剰な抽象化を排除
6. 注意点（Pitfalls）
- 将来的に再び階層が必要になる可能性がある（→ そのとき再導入すればよい）
- 型が変わることで、クライアントコードに修正が必要な場合がある
- もし多態性（ポリモーフィズム）を将来利用する計画があるなら、無理に統合しない
まとめ
- Collapse Hierarchy は「不要なスーパークラス／サブクラスを統合する」リファクタリング
- 判断基準：この階層は本当に意味があるか？ ただの名ばかりの抽象化ではないか？
- 基本思想：過剰な設計は排除し、クラス階層を必要最小限に保つ