オブジェクト指向設計ガイド

はじめに

オブジェクト指向設計ガイド
を会社で輪読会しているので、箇条書きでメモ

概要まとめてくれてる記事はあるので、重複がないようにする

オブジェクト指向設計とは、「依存関係を管理すること」であり、変更がかんたんになるように、どんなコード構成にするか。ということ
実用的な設計は、アプリケーションに何が起こるかを予測するのではなく、将来、何かが起こることをただ認めるだけ。

TRUEなコードを書くために、単一責任の法則をクラスに定義する

クラスに、「それと」や「または」といった風な説明ができてしまうとクラスの責務が一つ以上なのでよくない

・オブジェクトが何かを知るオブジェクトを知る何かのオブジェクト、のようにチェーンするのはよくない。あくまで知りすぎてはいけない。

・クラスが、他のクラスを知り過ぎるとよくない。なぜなら、そのクラスが密結合になり、汎用性がなくなる。更に、Aクラスを改修する時にBクラスにも影響が出て、修正がどんどん複雑化する(デメテルの法則の違反)。また、AクラスがBクラスしか操作しないといった意思にもなるため、クラスの汎用性にかける。

・別メソッドに切り分けることで、他のメソッドの依存を減らす

1
2
3
4


def wheel
  @wheel ||= Wheel.new(rim, tire)
  # 題材だとこう
end

ただ、疎結合にしすぎたらそれはそれで肥大化もするのか…

・引数の順番を指定するような initializeの書き方は、好ましくない、なぜなら、引数の順序を間違えた途端にバグるから。もし指定したいなら、ハッシュのargsの中に引数を全部埋め込み、merge や fetch を使って取得する

・引数が多ければ、Wrapperモジュールみたいのを作ってそこでパラメータの引数だけ管理する感じにすると楽かも

「クラス名を知っておく責任や、そのクラスに送るメソッドの名前を知っておく責任が、どこのほかのクラスに属するものではないかと疑える能力」
っていう言葉、忘れないようにしよう

設計を検討し、パプリックインターフェイスを定義し、シーケンス図
を使った章。

デルメルの法則 → オブジェクトを疎結合にするためのコーディング規則の集まり
メソッドチェーンになンになる hoge.fuga.piyo.piko みたいなのは許されない

設計するときはメッセージに焦点を当てる
メッセージをもとに適切なパブリックインターフェースを設計する