要約：「クラス設計の鉄則」-雑誌『Software Design 2025年5月号

記事の概要

この記事は
雑誌『Software Design 2025年5月号』
https://gihyo.jp/magazine/SD/archive/2025/202505
第2特集 もう一度学び直す クラス設計の鉄則 堅牢で変更に強いコードを作り上げる技術
の要約になります。

第1章 クラス設計再入門

クラス設計の基本は、以下の3つを意識する。

• モジュール性
• 関心の分離
• 依存関係

1. モジュール性

システムを独立性の高い部品（クラス）に分割し、役割や接続方法を明確にすること。単なるクラス分割ではなく、役割や関係が明確でなければ「大きな泥団子」になりやすい。

2. 関心の分離

1つのクラスが1つの関心事だけを扱うこと。とくに「計算判断」と「入出力」を分離し、金額や数量など業務独自のデータ型をクラスで表現することで、ロジックの重複や分散を防ぐ。

可視性（public, privateなど）を適切に使い、必要なものだけを公開する。publicが多い場合は関心の分離が不十分なサイン。

3. 依存関係

暗黙的な依存（重複や分散）を防ぎ、明示的な依存（参照関係）はシンプルに保つ。依存関係が多い・不安定な場合は設計改善が必要。

アプリケーション独自のデータ型を早い段階でクラス化し、ロジックの仮置き場として活用することで、設計改善のヒントが集まる。

第2章 迷わないクラス設計の指針

アプリケーションの関心事を

• 計算判断
• アプリケーションサービス
• プレゼンテーション
• データソース

の4つに分けて設計するのが現代的なアーキテクチャの基本。

「計算判断」→「アプリケーションサービス」→「プレゼンテーション/データソース」の順で設計し、依存される側から順に設計する。

1. 計算判断クラス

業務ルールや計算ロジックを担当し、アプリケーション独自のデータ型を不変（イミュータブル）で設計する。

2. アプリケーションサービスクラス

ユースケースや機能の流れを担当し、詳細な処理は他のクラスに委譲する。interfaceを活用して依存を分離する。

3. プレゼンテーションクラス

外部からのリクエスト受付や入出力変換を担当し、アプリケーションサービスクラスと疎結合にする。

4. データソースクラス

DBや外部APIとのやりとり・モデル変換を担当し、実装とinterfaceを分離する。

現代的な設計指針

現代的な設計指針として、「可変より不変」「エンティティより値」「継承よりコンポジション・サブタイピング」を重視する。これにより、変更に強く保守しやすい設計になる。

第3章 設計の落とし穴対策

• ソフトウェアは時間とともに設計が劣化するため、継続的な改善が重要。
• コードの整頓として「実行されないコードの削除」「小さく分ける（空白行やクラス分割）」「順番を整える（メソッドやif文の位置）」「コードで説明する（意味ある変数名や定数）」を実践する。
• 長いメソッドや大きなクラス、データだけ/ロジックだけのクラスは、関心の分離やモジュール性の観点から分割・再設計の候補。
• インスタンス変数や依存関係（import文など）に注目し、グループ化して新しいクラスに切り出すことで設計を改善できる。
• 良い設計は、実際に手を動かしてリファクタリングや分割を繰り返し、体験的に学ぶことが大切。設計の「感覚」を養うことが、より良いクラス設計につながる。

自分向けまとめ

要約に入っていない内容もありますが、自分に向けてのまとめ

• クラスは小さく
• 関連するデータとロジックを1つのクラスに
  • データだけのクラス、ロジックだけのクラスも作らない
• アプリケーション独自のデータ型を作る
• publicを使う箇所が増えてきたら、関心の分離がうまくいっていない
• 計算判断クラス、アプリケーションサービスクラス、プレゼンテーションクラスおよびデータソースクラスの順で設計
  • 計算判断クラスの設計
    • アプリケーション独自のデータ型クラス
    • アプリケーションに必要な計算判断の結果を表現するクラス
    • 内部のインスタンス変数の状態を変更しない、不変なクラス
• 使わないコードは削除する
• 小さく分ける方法
  • まずは空白行で分ける
  • 空白行で分けたら、クラスに分けられるか検討
• メソッドの定義の順番
  • 似た機能は近くに置く
  • 重要な機能は前に持ってくる
• コードに意味を持たせる。コメントで説明しようとしない