「良いコード／悪いコードで学ぶ設計入門」を読んだ

Amazon.co.jp: 良いコード／悪いコードで学ぶ設計入門―保守しやすい成長し続けるコードの書き方 eBook : 仙塲大也: Kindleストア

メモ

インスタンス変数の上書きは理解を難しくする
設計パターン
- 完全コンストラクタ
- 値オブジェクト
- ストラテジ
- ポリシー
- ファーストクラスコレクション
  - コレクション型インスタンスを不正状態から防御できる
  - コレクションの操作処理をクラスに集約することができる
- スプラウトクラス
static メソッドは低凝集な構造になりやすい
ファクトリメソッド
- 初期化ロジックの分散を防ぐことができる
- インスタンスの利用側クラスで, インスタンス生成ロジックが多くなり, 生成以外のロジックが希薄なることを防ぐことも可能
多すぎる引数
- プリミティブ型執着
  - 関数を汎用化しようと意識し過ぎると陥りがちなイメージ
単一責任の原則
- 同じ条件式を複数書かず、一箇所にまとめる
switch 文を書く前に, interface で switch を書かずに実現できないか検討する
- inteface 実装クラスの型を調べて分岐するのであれば意味がない
  - リスコフの置換原則に違反している
フラグ引数
- メソッドの機能を切り替える bool 型引数のこと
  - 関数利用者がフラグにより何が起こるか内部ロジックを見る必要が出るケースが発生する
密結合
- 責務が考慮されていないと密結合が発生しやすくなり, デバッグや変更が難しくなる
- 似ているロジックであっても概念が違えばDRYにするべきではない
- 継承
  - サブクラスはスーパークラスの構造に依存する（スーパークラス依存）
  - スーパークラス依存による密構造を避けるために継承より移譲を推奨
  - 移譲 == コンポジション構造にすること
  - テンプレートメソッドパターン
private メソッドの多いクラスは単一責任ではなく, 多くの責任を持っている可能性が高い
疎結合で高凝集を意識する
- 高凝集だけを意図して関係していそうなロジックを一箇所にまとめ上げたものの結果として密結合に陥っているケース
トランザクションスクリプトパターン
- データクラスとデータを処理するクラスで分けている場合に頻繁に実装される
- 低凝集密結合
null 例外や null チェックを避けるために null は返さず, 渡さないようにすることが大事