Open2
技術書を読んだ感想
nori0__技術書読んだ感想を雑多に記載する
nori0__良いコード／悪いコードで学ぶ設計入門
実装する時に改めて気をつけようと思った内容
- 関連しあうデータとロジックをクラスにする
- 他人がロジックがどこにあるか気づくやすくするため
- コンストラクタ経由で自分で正常値をいれる
- 生成ロジック(のパターン)が増えたらFactoryクラスへ移動する
- ログなど横断的な関心事はstaticメソッドでよい
- ロジックは呼ばれる側に書く
- 例えば class 装備 だと void 装備する void 脱ぐ となる
- 単一責任の原則に従う
- 同じ条件分岐は一ヶ所にまとめる
- interfaceを使うと条件分岐になる(=ストラテジパターン)
- 条件の重複を避けるためポリシーパターンを使いルールを規定する
- インターフェースを継承し1つクラスに1つのルールを表現
- このときリスコフの置換原則に注意すること。継承元の仕様が継承先と同じかどうか？をチェック
- フォルダ分けはビジネス概念でおこなうこと
- 設計パターンだと関連がわからなくなるため
- 命名は会話にでてくるものが良い
- 違いが形容詞で表現されている名詞はクラスにできないか検討する
- たとえば「このフラグがたっているときのUserは要注意会員」などメソッドが動詞＊目的語担っている場合は責任が異なるものが一緒のクラス担っている可能性がある、別々のクラスに分けるべき
- MemberManagerクラスにgetHitPointメソッドを持っている場合、HitPointクラスを設計できないか検討する
- メソッドはコマンド（状態変化）とクエリ（状態を返す）で分ける
- モデルは目的別にする
- システムは目的を達成するために作られているため
- そのため現実の物理的な存在と情報システム上のモデルは1：多になるケースがある
- たとえばユーザーは1人だがアカウント、プロフィールと別のモデルになる
感想
- いわんとしていることはわかるが、具体的なコードはなく参考にするには不完全という印象
- サンプルコードいまいちだなあと思っていたら良い記事見つけた。こちらの記事も併せて読んだ方が良い
- 15章以降の、リファクタはちょっとずつやろうとか仲間を集めることが大事はとてもよくわかる