【Ruby】「オブジェクト指向設計実践ガイド」を読んだ

総評

オブジェクト指向は理解しているつもりだったが、Rubyに対してどう適用するかがわかりやすく解説されていて、凄くいい本だった。また、設計やリファクタリングをする上での心構えなどについても記載されていて、改めて大切さを認識できた。

概要

変更可能なコードが書けるようになるためには、「オブジェクト指向の理解」、「リファクタリング技術」、「価値の高いテストを書く能力」の３つが必要。「オブジェクト指向の理解」「リファクタリング技術」は、継承・ダッグタイピング・コンポジションの使い分けが重要。「価値の高いテストを書く能力」は、最低限必要なテストを見極めることが重要。

備忘録

備忘録として、印象に残った箇所を書き留めておく。

設計・リファクタリング

無闇にリファクタリングを行うのではなく、与えられた時間で最善を尽くす
→将来的なコスト軽減の大きさと、目先のコストを正しく比較する
メソッドも単一の責任をもつようにする
→このリファクタリングは最終的な設計がわかっていない場合にも実施すべき
→複数の責任を持つメソッドは変更が必要になった場合のコストが高くなる
具象と抽象を意識し、具象には依存しないようにする
→抽象的なモノは変更されにくいので、自分より変更されないものに依存する
Rubyでは、あえてprotectedなどのキーワードを付けず、「_」などで明示するのみにする場合がある
→今の自分より将来のプログラマーのほうが持っている情報が多いため、信じる
設計の目的はコストを下げること
サブクラスを１つだけ持つ抽象クラスは作成する必要がない、具体的な要求が出てきてからで遅くない
抽象クラスを追加するときは、他のサブクラスで共有するメソッドのみを抽象クラスに移動する
StringUtils.empty?(hoge)などは不要、オブジェクトは自身を管理すべき
継承が間違って使われたときの代償は大きい、書いたコードをどのような人が使うかに基づいて調整すべき
テストは量よりも質、不必要なテストにかかるコストは高い

Ruby文法

# Structのメソッド定義
Hoge = Struct.new(:hoge) do
  def fuga
    hoge
  end
end

# delegate
delegate :hoge, to: :something

# モンキーパッチ
# 組み込みクラスの拡張を行える
class Array
  def hoge
    hoge
  end
end

# ダッグタイプ
# インターフェースなどの定義せず、異なるクラスで同じメソッドを呼べるようにする
class Hoge
  def piyo
    piyo
  end
end

class Fuga
  def piyo
    piyo
  end
end

# OpenStruct
# 要素を動的に追加・削除できる
hoge = OpenStruct.new
hoge.fuga = piyo

# テストダブル
http://tbpgr.hatenablog.com/entry/2016/12/12/222331