Java | オブジェクト指向：神クラス（God Object）

神クラス（God Object）とは何か
典型例：神クラス臭のする OrderSystemManager
1. 何でもやるクラスのイメージコード
なぜ神クラスがヤバいのか（重要なポイント）
神クラスになりかけている兆候を見抜く（深掘り）
本来あるべき姿：神クラスが“分解された世界”
1. 責務ごとにクラスを分けるイメージ
2. 「こいつは神クラスじゃないか？」と気づいたときの思考
神クラスを避けるための、日々の小さな習慣
まとめ：神クラスは“便利屋”の顔をした「負債の貯蔵庫」

神クラス（God Object）とは何か

神クラス（God Object）は
「システムのあらゆることを“何でも知っていて、何でもやろうとする”巨大なクラス」
のことです。

画面の制御もやる。
ビジネスロジックも全部持つ。
DB からの読み書きもやる。
外部 API も叩く。
ログも出す。
設定も持つ。

とにかく「全部このクラスから始まる」みたいな存在です。

最初は「ここを見れば全部分かるから便利」に見えるんですが、
成長すればするほど、変更が怖くなり、バグが埋もれ、誰も触れない“ボスキャラ”になります。

典型例：神クラス臭のする OrderSystemManager

何でもやるクラスのイメージコード

イメージしやすい神クラスの例を、ざっくり Java で書くとこんな感じです。

public class OrderSystemManager {

    // 全ドメインを握るフィールドたち
    private final UserRepository userRepository;
    private final OrderRepository orderRepository;
    private final ProductRepository productRepository;
    private final MailSender mailSender;
    private final PaymentGateway paymentGateway;
    private final Logger logger;

    public void registerUser(UserRequest request) {
        // 入力チェック
        // パスワードハッシュ
        // User エンティティ生成
        // DB 保存
        // メール送信
        // ログ出力
    }

    public void placeOrder(OrderRequest request) {
        // ユーザ取得
        // 商品取得
        // 在庫チェック
        // 合計金額計算
        // 割引計算
        // 決済実行
        // 注文保存
        // メール送信
        // ログ出力
    }

    public void cancelOrder(long orderId) {
        // 注文取得
        // 状態チェック
        // 返金処理
        // 在庫戻し
        // 状態更新
        // メール送信
        // ログ出力
    }

    public void exportOrdersToCsv(LocalDate from, LocalDate to) {
        // 注文一覧取得
        // CSV 生成
        // ファイル出力
        // ログ出力
    }

    // さらに 20 個ぐらいメソッドが続く…
}

public class OrderSystemManager {

    // 全ドメインを握るフィールドたち
    private final UserRepository userRepository;
    private final OrderRepository orderRepository;
    private final ProductRepository productRepository;
    private final MailSender mailSender;
    private final PaymentGateway paymentGateway;
    private final Logger logger;

    public void registerUser(UserRequest request) {
        // 入力チェック
        // パスワードハッシュ
        // User エンティティ生成
        // DB 保存
        // メール送信
        // ログ出力
    }

    public void placeOrder(OrderRequest request) {
        // ユーザ取得
        // 商品取得
        // 在庫チェック
        // 合計金額計算
        // 割引計算
        // 決済実行
        // 注文保存
        // メール送信
        // ログ出力
    }

    public void cancelOrder(long orderId) {
        // 注文取得
        // 状態チェック
        // 返金処理
        // 在庫戻し
        // 状態更新
        // メール送信
        // ログ出力
    }

    public void exportOrdersToCsv(LocalDate from, LocalDate to) {
        // 注文一覧取得
        // CSV 生成
        // ファイル出力
        // ログ出力
    }

    // さらに 20 個ぐらいメソッドが続く…
}

Java

OrderSystemManager という名前ですが、
ユーザ登録、注文、決済、メール送信、CSV 出力、ログ…何でもやっています。

このクラス一つが、システムのあらゆるドメイン（ユーザ・注文・商品・決済）にべったり依存し、
「中心どころか全部を握っている」状態です。

なぜ神クラスがヤバいのか（重要なポイント）

変更の影響範囲が読めない

例えば、「注文時の割引ルールを変えたい」とします。

本来なら「割引を担当しているクラス」を開いて直したいところですが、
神クラスだと、割引ロジックが placeOrder メソッドの中に直接書かれているかもしれません。

しかも、同じ割引ロジックが別メソッドにもコピペされていたりします。

割引ロジックを変えたいだけなのに、

placeOrder の中
recalculateOrderAmount の中
exportOrdersToCsv の中

など、複数のメソッドを探して全部修正しないといけない。

そして、「どこか 1 か所の修正を忘れてバグになる」というのが、神クラスあるあるです。

テストがほぼ不可能に近づいていく

神クラスは、たいてい依存オブジェクトが大量です。

UserRepository
OrderRepository
ProductRepository
MailSender
PaymentGateway
Logger
…

ユニットテストを書こうとすると、

全部をモックするセットアップ
あるいは本物の DB やメール送信を動かす羽目

になります。

「この小さなロジックだけテストしたい」のに、
クラスが巨大すぎて、その小さなロジックだけを切り離せない。

結果、「まともなテストを書く気が失せて、結局手動テストに頼る」という流れになります。
テストがないから怖くてリファクタリングできず、さらに神クラスが太る、という悪循環です。

責務がごちゃ混ぜになり、誰も全体を理解できなくなる

神クラスは、「やっていることの種類」が多すぎます。

ビジネスルール
DB アクセス
外部 API 呼び出し
トランザクション管理
入力チェック
ログ
メール送信
ファイル出力

これらが一つのメソッド内で入り乱れます。

コードを読んでいると、「今どの層の話をしているのか」が分からなくなってきます。

ビジネス的に重要なロジックを見たいのに、
SQL やメール文面の組み立て、ログ出力などに視線が奪われる。

結果、システムの肝心なルールがコードの中に埋もれていきます。

神クラスになりかけている兆候を見抜く（深掘り）

兆候1: クラスを開くとスクロールバーが豆粒

単純ですが効きます。

クラスファイルを開いてみて、

画面のスクロールバーがほぼ一番上に張り付いていて、小さな点に見える
メソッド一覧（IDE のアウトライン）を開くと、スクロールしないと全部見えない

といった状態なら、そのクラスはかなり危険ゾーンです。

特に 〜Service や 〜Manager、〜Controller などがそうなっていたら、「神化」が進行しています。

兆候2: 「とりあえずここにメソッド足しとくか」が口癖になっている

新しい仕様が来たときに、

「まあ今回もとりあえず OrderSystemManager にメソッドを1個足して…」

と、毎回同じクラスにメソッドを追加していないかどうか。

これを繰り返していると、そのクラスはあっという間に「全部持ってるクラス」になります。
「この処理、名前的にここしかないよね」と安易に突っ込む前に、「本当にこのクラスの責務か？」を一度立ち止まって考える必要があります。

兆候3: フィールドとコンストラクタ引数がやたら多い

神クラスは、たいてい依存する相手も多いです。

UserRepository
OrderRepository
ProductRepository
MailSender
PaymentGateway
ReportGenerator
CsvExporter
NotificationService
…

フィールドの数、コンストラクタ引数の数が増えれば増えるほど、
そのクラスが担当している領域の広さも増えています。

コンストラクタ引数が 5 個を超え始めたら、「そろそろ責務を分けるべきじゃないか？」と疑うサインです。

本来あるべき姿：神クラスが“分解された世界”

責務ごとにクラスを分けるイメージ

さきほどの OrderSystemManager を、責務ごとにスパッと分けると、
だいたいこんな方向になります。

ユーザ登録関連 → UserRegistrationService
注文受付 → PlaceOrderService
注文キャンセル → CancelOrderService
レポート作成 → OrderReportService
メール送信 → OrderMailService or ドメインイベント＋リスナー

さらに、ドメインモデル側にも責務を移します。

注文の状態遷移ルール → Order エンティティのメソッド（cancel(), ship() など）
金額計算 → Order や OrderLine、Money のメソッド
在庫引当 → InventoryService

こうして、「全部1クラス」ではなく「役割ごとに複数クラス」が協調する構造にすると、
一つ一つのクラスはだいぶ小さくなります。

「こいつは神クラスじゃないか？」と気づいたときの思考

神クラス候補を見つけたら、こう自問してみてください。

このクラスがやっていることを、ざっくりグルーピングしたら何種類ある？
そのグループごとに、クラスを分けられないか？
ビジネスルールは本来ドメインモデル側に寄せられないか？

たとえば placeOrder メソッドを眺めて、

入力検証
ドメインオブジェクトの生成
ビジネスルール（割引、在庫チェック）
DB 永続化
メール送信

という感じで色分けして考えると、
「これとこれは別クラスに切り出せるな」というイメージが湧きやすくなります。

神クラスを避けるための、日々の小さな習慣

ここからは、具体的なテクニックというより「癖」の話です。

新しいメソッドを書くときに、「このメソッドはどのクラスに書くのが一番自然か？」を考える
「〜Service」や「〜Manager」に何でも集めない
「この if/switch は、本当は別のクラス（状態・種別）の責務じゃないか？」と疑う
ドメインモデル（User, Order, Money など）に積極的に振る舞いを持たせる

こういう感覚を少しずつ育てていくと、
「神クラスを作りたくても作れない体質」になっていきます。