【勉強３】現場で役立つシステム設計の原則

勉強で「現場で役立つシステム設計の原則」を読んだので、個人的に要点をまとめています。表現が正確でない点もあるかと思いますが、あくまで個人的な整理ですのでその点ご理解いただければ幸いです。

前半

Chapter1　小さくまとめてわかりやすくする

キーワード
  • 変更が大変なプログラムの特徴
  • 説明用変数の導入、破壊的代入
  • メソッドの抽出
  • ドメインオブジェクト
  • 業務ロジック
  • 値オブジェクト
  • 完全コンストラクタ
  • コレクションオブジェクト（ファーストクラスコレクション
メモ
  • 変更が大変なプログラムは以下の特徴がある
    •  メソッドが長い
      • if-else分が入り混じるとバグが混入しやすい。
    • クラスが大きい
      • 変更が必要な箇所がクラスのどの部分かが分かりにくくなる。
    • 引数が多い
      • 変更時のどの引数が関係し、どの引数が関係しないかの見極めが難しい。
      • 引数が多いと必然的にめそっどが長くなりif文も増える。
  • 説明用変数の導入：計算の目的ごとに新しい意味のある名前を付けて変数を作る。逆に1つの変数を使いまわすのを破壊的代入と呼ぶ。
    • 説明用変数を積極的に導入することで破壊的代入が減り、プログラム変更時のバグが減る。
  •  メソッドの抽出
    • ある目的（送料計算）の計算をメソッド・関数で切り出すことで、メソッド内の変更を中に閉じ込めやすくなる。 
    • 異なるクラスにロジックが重複している場合は、別のクラスを新規作成し共通のロジックの置き場所とする（例では送料クラスを新たにつくり、送料クラスのインスタンスを立ち上げamountメソッドを呼び出す。）
  • ドメインオブジェクト：業務で使われる用語（ex 送料）に対応するクラスのこと。業務の構造とプログラムの構造が一致すると良い。
    • 送料計算のたった2行のメソッドすらも切り出すのが、変更を容易にする。
  • 業務ロジック：計算（合計、端数の丸め込み）、判定（期限切れ名の判定）、加工（フォーマット）
  • 値オブジェクト（Value Object）
    • 金額をただintで宣言したり、電話番号をstringでただ宣言するのは危険。
    • 専用のクラス（Quantity、Telphone）をつくり、そこに制約を課す。
    • 全ての関数の引数は値オブジェクトを受け付けるようにすると安全
  • 完全コンストラクタ
    • 値オブジェクトは内部の変数を変更不可にし、新しい値（ある商品の値から1000円割引など）は別のオブジェクトを返すようにする。
  • コレクションオブジェクト（ファーストクラスコレクション）
    • リストなどの要素の追加・削除・書き換えは、そのコレクションオブジェクトの中に閉じ込める。
    • コレクションオブジェクトを返すときは、必ず別のオブジェクトを返し、かつ買い替え不可能にする
まとめ

「業務の関心ごと」と「クラス」を一致させること。業務の関心ごとに業務ロジック（計算・判断・加工）と制約・約束事を詰め込む

Chapter2　場合分けのロジックを整理する

追記中...