【Java】リファクタリング方法について（責務が肥大化したクラスの分割方法）

はじめに
リファクタリングとは
1. 目的
「神クラス」
クラスを分割すべきかどうかの判断基準
リファクタリングの方針
まとめ
ドキュメント
最後に

はじめに

Javaの現場で仕事をしていると、避けて通れないテーマが「リファクタリング」です。長く運用しているシステムであったり、機能追加や仕様変更を繰り返すうちに、コードは少しずつ複雑になり気づけば「動くけど触りたくない」となるソースコードが発生してしまいます。
特に厄介なのが、責務が肥大化したクラス、いわゆる「神クラス」です。

修正するたびに影響範囲が広がっていく
テストが書きづらくなる
読むだけで疲れる

今回は、リファクタリング方法について、ログとして記載していきたいと思います。

他にも、体系的にJavaを学びたい方には以下の教材がおすすめです：

👉スッキリわかるJava入門
👉スッキリわかるJava入門実践編

リファクタリングとは

リファクタリングとは、プログラムの外部仕様（振る舞い）を変えずに、内部構造を改善することです。動きはそのままで、中身のソースコードを読みやすく、壊れにくくしていく作業になります。

目的

実務におけるリファクタリングの目的は、以下のようなものが挙げられます。

コードの可読性を高めて理解しやすくする
修正時の影響範囲を小さくする
バグを入りにくくする

「神クラス」

「神クラス」は、前述したとおり責務が肥大化したクラスのことです。特徴を挙げていきます。

特徴１：クラス名と中身が一致していない

「Userservice」というクラス名なのに、「実処理」「検証」「DB接続」「ログ出力」「メール送信」等、すべての処理を1つのクラスで実施している状態は、クラス名と中身が一致せず、クラスの責務が曖昧になり、理解コストが急激に上がります。

特徴２：メソッド数が異常に多い

メソッド数が多いクラスは、読む前から心理的にもやる気が失せ、「できれば触りたくない存在」になります。

1つのクラスに対してメソッドが数十個存在している
スクロールを大量に実施しないと全体が把握できない

特徴３：修正のたびに別機能に影響がある

修正のたびに別機能に影響があるクラスは、典型的な神クラスです。

一部を修正すると、別の機能に影響し処理結果が変化したり、エラーとして落ちる
影響範囲が大きすぎて誰にも把握できない

クラスを分割すべきかどうかの判断基準

次に、神クラスをどう分割すべきかの判断基準について、紹介していきます。

判断基準１：クラスが修正される理由が1つではない

まず、対象のクラスに対してどのような修正が今まで入っているかを確認します。もし、修正理由が複数存在するならそのクラスは複数の責務を持っている可能性があります。1つの変更理由につき、1つの責務を持っているという感覚が、分割すべきかどうかが判断しやすくなります。

業務ルールが変わったから修正した
DB仕様が変わったから修正した
出力形式を変えるために修正した

判断基準２：メソッドがグループ分けできるか

クラスの中にある複数のメソッドに対して、それぞれグループ分けができるかを確認します。グループ化できるのであれば、それは分割の判断基準となります。

入力チェックの処理
DB操作の処理
通知処理
外部連携処理
出力処理

判断基準３：テストコード・ケースが書きづらくないか

テストコードやテストケースが書きづらくないかを確認します。こうした状態は、クラスがやることを抱えすぎている証拠です。

一部の処理だけテストしたいのに、全部準備が必要
モックやスタブが増えすぎる
テストを書く前から条件が多すぎてつらい

リファクタリングの方針

リファクタリングを実施するときに、一番大切なのは「安全に進めること」 です。きれいにすることより、現状の動きを壊さないことを優先します。

方針１：振る舞いは絶対に変えない

リファクタリングは、機能追加や仕様変更とは別物です。リファクタリングの際に、ついでに機能修正を実施するとトラブルの元になります。修正前と修正後の実施結果が同じであることが最優先となります。

方針２：一気にやらず、小さく進める

神クラスを見たとき、「まとめて全部直したい」と思いがちですが、それは失敗しやすいパターンです。
実際のリファクタリングでは、1つの責務だけ切り出し、一つずつ動作確認をするという小さなステップで進めます。

方針３：元のクラスはすぐに消さない

分割後、元のクラスをいきなり消す必要はありません。それより、元の暮らすを呼び出し用のクラスにして調整役として残しておく方が、リファクタリング前後の流れを理解しやすく失敗しにくいです。

まとめ

責務が肥大化したクラスは、誰かの設計ミスや手抜きの結果ではなく、多くの場合、「その時点で一番早く、安全に動かすための選択」の改修を実施した結果として生まれ他のかと思います。
だからこそ、神クラスを前にしても、いきなり否定したり、無理に壊したりするのではなく、時間ができたタイミングで、今回記載した観点で適切なリファクタリングを行い、保守していくことが重要です。