神クラス — 1つのクラスが何でも知っている

UserManager、AppService、Helper——名前からして何でも入りそうなクラスが、気づけば3000行。新機能のたびに「とりあえずここに足す」を繰り返した結果できあがるのが神クラスです。

横にスクロール

症状：どう気づくか

• 1つのクラスが数千行あり、メソッドが数十個ある。
• 名前が Manager / Service / Util / Helper など何でも入りそうな抽象語。
• そのファイルを開くとコンフリクトが頻発する（全員が触るため）。
• 「この機能どこ？」と聞くと、答えがいつも同じクラス。

なぜ悪いのか

神クラスは、本来別々であるべき責務とデータを1箇所に握り込みます。すると2つの形で開発が止まります。

第一に、変更が波及する。表示のための小さな修正が、同じクラスに同居する課金や認証のロジックに影響しうる。だから誰もが変更を怖がり、レビューも重くなる。

第二に、テストできない。神クラスをインスタンス化するだけで、DB・外部API・設定・他サービスがぞろぞろ必要になる。一部の振る舞いだけを切り出して検証することができず、結局テストが書かれません。

直し方

一気に作り直すのは危険です。凝集した塊を1つずつ切り出すのが安全な道です。

1. 一緒に変わるものを見つける。 同じデータを触り、同じ理由で変更されるメソッド群は、1つの責務の候補。
2. 新しいクラスへ切り出す。 その塊を別クラスに移し、神クラスからは委譲（呼び出し）でつなぐ。外から見た振る舞いは変えない。
3. テストを添える。 切り出した小さなクラスにテストを書く。これが次の分割の安全網になる。
4. 繰り返す。 神クラスが薄くなるまで、塊ごとに反復する。

Before: UserManager（3000行）
  認証・プロフィール・課金・通知・レポート… 全部入り

After:
  Authenticator     … 認証だけ
  ProfileService    … プロフィールだけ
  BillingService    … 課金だけ
  UserManager       … 上記を束ねる薄い窓口（あるいは消滅）

まとめ

• 神クラスは、多くの責務とデータを抱え込んだ巨大クラス。Manager/Service/Util のような曖昧な名前が兆候。
• 害は2つ。変更が全体に波及することと、依存が多すぎてテストできないこと。結果、変更が滞る聖域になる。
• 直し方は責務ごとの切り出し。凝集した塊を別クラスへ移し委譲でつなぐ。単一責任（変わる理由は1つ）が指針。
• 分割しすぎも害。数でなく変更理由で割る。