現場で役立つシステム設計の原則 ch1-3
ch1 小さくまとめてわかりやすくする
- 変更を楽にするために
- 名前を略さない
- コードを段落に分ける
- 説明用の変数の導入
- 破壊的代入をしない
- コードの段落をメソッドに切り出す
- 業務の関心事に対応したクラスを作る
- ドメインオブジェクト
- 「送料クラス」とか
- ドメインオブジェクト
- コードの意図をわかりやすく説明するためなら1行の計算式でもメソッドに独立させる
- 【所感】「わかりやすい」ことと抽象化が大事だと思う
- メソッドの呼び出しと中身を両方読まないと結局理解できない類の分割はやりすぎ
- (A Philosophy of Software Design -- Conjoined Method Red Flag)
- 【所感】「わかりやすい」ことと抽象化が大事だと思う
ch2 場合分けのロジック
- ガード節でシンプルに
- else句がなくなり、複文から単文の羅列になるため、条件文どうしが疎結合になる
- 区分オブジェクトの導入
- 料金計算の「大人」「子ども」「シニア」みたいなやつ
- 多態
- State PatternのStateオブジェクトみたいなやつ
AdultFee ..|> Fee- 一覧性に欠けるという欠点がある
- 列挙型
- Javaでは列挙型もクラスなので振る舞いを持てる
ch3 業務ロジックをわかりやすく整理する
- データと振る舞いを分けるな
- メソッドではインスタンス変数を過不足なく使え
- 一部しか使わないならクラス分割
- 高凝集の秘訣
- 【所感】APoSDでいう「Classitis」に陥らないか不安
- 個々のモジュールは確かにシンプルになる
- が、モジュールのインタフェースが増え、システム全体としての複雑性は上がってしまいそう
- ドメインオブジェクトに業務ロジックを一元化する
- 三層+ドメインモデル
| 名前 | 役割 |
|---|---|
| プレゼンテーション層 | UIなど外部との入出力(V,C) |
| アプリケーション層 | 業務機能のマクロな手順の記述 |
| データソース層 | データベースとの入出力 |
| ドメインモデル | ドメインオブジェクトの集合 |
- 三層は、データストアクラスではなくドメインモデルに依存する
