【設計の原則】良いクラス・悪いクラス

この章でやること

読み物中心の章です。前回までで「クラスを書ける」ようになりました。この章のテーマは「良いクラスと悪いクラスを見分けられる」ようになることです。

世の中には設計の良し悪しを判断する有名な原則集があります。SOLID原則。5つの原則の頭文字です。面接でも「SOLIDを知っていますか」はたまに飛んでくる質問ですが、5つ全部を腹落ちさせるのは無理があります。この章では、実務での遭遇率が高い3つに絞ります。しかも、そのうち2つはあなたがもう体験済みです。

原則1: 単一責任(クラスの仕事は1つ)

まず、悪いクラスの代表格を見てください。実務のコードベースで実際に育ちがちな姿です。

// 悪い例: なんでもやるクラス
class UserManager {
  register(name: string, password: string) { /* ユーザー登録 */ }
  checkPassword(password: string): boolean { /* パスワード検証 */ }
  saveToDatabase() { /* DBへの保存処理 */ }
  sendWelcomeEmail() { /* 登録完了メールの文面作成と送信 */ }
  exportCsv(): string { /* 管理画面用のCSV出力 */ }
  calcMonthlyFee(): number { /* 月額料金の計算 */ }
}

一見便利そうですが、このクラスには変更の理由が多すぎます。メールの文面変更でも、料金プラン改定でも、CSVの列追加でも、DBの構成変更でも、全部このクラスを開くことになる。こういうクラスは神クラスと呼ばれ(何でも知っている、の皮肉です)、次の問題を起こします。

・ 誰かが料金計算を直した変更が、無関係なはずのメール送信を壊す(1つのクラス内はお互いに触れるので、思わぬ共有が起きる)

・ チームの複数人が同じファイルを触り、修正が衝突し続ける

・ テストが書きにくい(メール送信のテストにDB接続の準備が要る、など)

単一責任の原則(Single Responsibility Principle)は、これを禁じます。クラスを変更する理由は、1つであるべき。上の例なら、登録・認証を担う UserAccount、保存を担う UserRepository、メールを担う WelcomeMailer、料金を担う FeeCalculator に分けます。クラスの数は増えますが、変更のたびに開くファイルは1つで、影響範囲もそこで閉じます。