オブジェクト指向シリーズ。読みにくい本が多い中でオブジェクト指向設計実践ガイドは勉強になるなー。
依存関係の管理
メモ
- オブジェクト指向では共同の仕組みが大半なため、必然的に大量の依存関係を生む(p62の図)
それが本当に必要か?をつねに考える(例 インスタンスそのものの参照、引数の対応、メソッドを直で対応させる・・) - 依存しているオブジェクトに変更があったら?を常に考える(P66)
- 疎結合により対象が変更してもコードが変わらない。対象の変更の影響を受けないようにする(P66のWheelの例。DIの一種)
- クラスを丸ごとインスタンスの際にとれれば、インスタンス変数の変更影響を受けない。最悪それができなければインスタンス内で依存のインスタンス作成を行う。
- P71のようなラッパーメソッドを作ること(def diameter)により、外にあるクラス(wheel)のメソッドの変更の影響が受けにくくなる
- 依存の少ないもののほうに変更の可能性があるクラスの依存を預ける(この場合でいうとWheelにGearを預ける)→依存度の方向の逆転
- 依存度の高さと変更の可能性を常に見る
実際のコーディング上のコツ
- 外部クラスのインスタンス作成をなるべく行わない
- 外部クラスのメソッドに関してはラッパーメソッドを使う(p70)
- インスタンス生成の場合、複数の受け入れ方を前提としておく
- インスタンス生成の際にハッシュを使う→固定化された順番の引数への依存度を下げることができる。ただし絶対固定のものは残しておく(絶対必要なもの＋オプションを配列化するのがよさげ)
- ディフォルト値の設定→歯抜けだったり、ある引数が使われない場合もバグにならない
- インスタンス生成を外部化する
感想
いままではクラス間の依存関係に無頓着だった・・というかそういうものだと思っていたので、問題化してないかったなー。
DIに関しての本質を言うと、数学でいうと数字を使わずに文字(x)を使う、みたいなニュアンスだと思う。こうすると数字が変わっても変数なので変更に依存しない。DIを初めて見たときはわけがわからなかったけど、今となるとそのすごさがよくわかる。P71のラッパーメソッドも最初見たときは意味が分からなかったが今だとそのありがたみがわかる。依存に関しては業務要件の理解度にもつながってくるかもしれない。※変更しやすさについての理解など。
