第5回「オブジェクト指向設計実践ガイド」読書会に参加しました

11/1 NSEGの「オブジェクト指向設計実践ガイド」読書会の第5回に参加しました。参加者7名でした。

nseg.connpass.com

今回は第5章を読みました。

オブジェクトの型(クラス)を調べて処理を変えるというコードの例としてcase文が使われてました:

case preparer
when Mechanic
  preparer.prepare_bicycles(bicycles)
when TripCoordinator
  preparer.buy_food(customers)
when Driver
  preparer.gas_up(vehicle)
  preparer.fill_water_tank(vehicle)
end

本に何の説明も書かれてなかったのでRubyを知らない人は、このようにcase文でクラスの判定ができるということがわからなかったようです。

Rubyのcase文は単純な一致比較だけでなく、文字列が正規表現に適合するかとか、上の例のようにクラスのオブジェクトかどうかを調べたり、when に書かれたオブジェクトによって色んな比較が便利にできるのですが、その仕組みは単純で、

case a
when b
  ...

は、b === a を判定しているにすぎません。

基底クラスであるObjectの === メソッドは単純一致比較、正規表現の === メソッドは正規表現に適合するかどうかの比較、Classの === メソッドはオブジェクトがクラスインスタンスかどうかの比較というように、各オブジェクトに適切な === メソッドを定義することで自然にcase文が記述できるようになっているのです。

まさにこの章の本題である「抽象的なパブリックインタフェースを取り決める」ということが実装されている例になってますね。

後半、静的型付けと動的型付けの比較をしていますが、静的型付けのメリットを過小評価してるような気がしました。コンパイル時の型検査を "コストが高い割にわずかな価値しか得られない深刻な制約" と書いていたり。

本の中で静的型付けのメリットとして挙げられてますが、