第20章 このクラスは大きすぎて、もうこれ以上大きくしたくありません

ちょっとした変更の場合、最も簡単な方法は既存のクラスにコードを追加する方法
しかし、追加し続ければ、結果的に長いメソッドを持つ巨大なクラスになってしまう
このような状態は、理解するのに多くの時間がかかるようになる

巨大なクラスのデメリット

• 変更の影響を把握するのが困難になる
• 作業計画の調整が難しくなる
• テストが難しくなる

このような状況を悪化させないためにどのようにするべきか(詳細は 6章を参照)

• スプラウトクラス
• スプラウトメソッド

特効薬はリファクタリング
クラスを小さなクラス群に分割するのに役立つ
小さなクラスに分割する指針→単一責務の原則(参照)

メソッド分類法
コードの責務を把握する方法の一つ
同じ責務を持つメソッドまとめグループに分類する方法

コードの責務を把握する経験則

• メソッドを分類する
  • 名前が似ているメソッドを探す
  • アクセス属性と一緒に書き出し、一緒にできそうなのを探す
• 隠されたメソッドを調べる
  • privateとprotectedメソッドが多く含まれる場合、そのクラスの中から別クラスを取り出せすことを示唆する
• 変更可能な決定事項を探す
  • 決定事項を探す
    • DBへのアクセスや、他のオブジェクトなどがハードコードされいること
• 内部的な関係を探す
  • インスタンス変数とメソッドの間の関係を探す
• 主要な責務を探す
  • クラスの責務を一文で説明してみる
• 他のすべての経験則が役に立たない場合、試行リファクタリングを行う

大きなクラスの中のたくさんの異なる責務を認識できたら、あとは戦略と戦術の２つの問題のみ

• 戦略
  • 責務を識別し、チーム全員に責務を理解させ、必要に応じて分割する
• 戦術
  • 最初に実装レベルで単一責務の原則を適用する
  • その後インターフェースレベルでも導入する

感想

個人的にメソッドを分類するは、賛成できない
たまたま中身が一緒なだけで、責務が違う処理を一緒にする恐れがあるから(Userクラスの例の動画とか)