「オブジェクト指向設計実践ガイド」 Sandi Metz 著，髙山泰基 訳
感想
- オススメ度 5/5
- ある程度railsで開発慣れてきたけど、設計で行き詰ることが多くなってきたときに読んだ
- その後の設計の指針になることが多く書いてあった
- 「どのクラスになにをしてもらうかから設計を考える」とか
メモ
1章. オブジェクト指向設計
- 少しずつ形になるように実装していく(Agile的)
- ゴールは変更しやすいアプリケーション設計をすること
2章. 単一責任のクラスを設計する
- クラスは一文で説明できるように
3章. 依存関係を管理する
- hash.fetch使うと便利
- 疎結合なコードを書く(依存オブジェクトの注入)
- 自分よりも変更されないものに依存する
4章. 柔軟なインターフェースをつくる
- 設計方針: 「このメッセージを送る必要があるけど、だれが応答すべきか」という考え方
- メッセージを送るためにオブジェクトは存在する
- メソッドは"どのように”よりも”なにを"
5章. ダックタイピングでコストを削減する
6章. 継承によって振る舞いを獲得する
7章. モジュールでロールの振る舞いを共有する
- ロール(実装クラス)が RoleA.class, RoleB.class, RoleC.classがある場合、インターフェースとなるHogerable.moduleを実装して、各ロールにincludeさせてあげると、使うほうは使いやすい
- 抽象スーパークラス内のコードを使わないサブクラスはあってはいけない
- typeで分岐して処理が呼ばれるとか、classで分岐して処理が呼ばれる場合は、ロール実装を考える
- 継承する側でsuperを呼び出すのは避ける
- Parent#hoge{ local_hoge()} として、Chile.#local_hogeを実装するほうがいい
- 改装構造を浅くする
8章. コンポジションでオブジェクトを組み合わせる
- コンポジション
- メリ: 構造的に独立する。見通しよくなる。
- デメ: 明示的にメッセージ移譲をする必要がある(コスト)
- 継承
- メリ: シームレスに移譲する。サブクラスの実装はやい。
- デメ: 親クラスの変更コストが高い。親クラスが思ってないような使われ方される可能性あり。
- 迷ったときはコンポジション
- 依存度を下げられるので
- is-a => 継承
- is-a => …の一種 A, B, Cが子の場合。A+B+Cで親になる。
- behaves-like-a => Mixin
- has-a => コンポジション
- has-a => …に含まれる A, B, Cが子のの場合。A+B+Cより親のが大きい。