本当に良い本でした。読んで良かった。初心者を中心に中級者にも刺さる
本だと思います。輪読などして、チームで読むとオブジェクト指向設計の
そもそもの話をしなくて良さそうです。

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 amazon.co.jp

難しい話が易しく説明されており「あ、そうだったのか」と思うことが度々
でした。ボリュームも全９章とコンパクトで、１日１章読むのに丁度よかっ
たです。

読んでメモった箇所を中心にまとめていきます。

第２章 単一責任のクラスを設計する

インスタンス変数へのアクセス方法を誤解していました。

P46
変数はそれらを定義しているクラスからでさえも隠蔽しましょう

今まで他のクラスから隠蔽する時は、直接 @hoge などにアクセスしてい
ましたが、中からも attr_reader などで隠蔽する必要があるそうです。
「データではなく、振る舞いに依存する」ためだそうです。

メモ化などでこうした手法は使っていたけど、単純な参照も隠蔽する必要
があるのですね…。

ただ、中からしか使わない変数も単純な attr_reader を使っていたのは、
納得いかなかったです。こうして外から隠蔽する必要はないでしょうか？

class Hoge
  attr_reader :hoge # 外からも参照される

  #...

  private
  attr_reader :hogehoge # 中からしか参照されない

  #...
end

第３章 依存関係を管理する

「依存オブジェクトの注入（DI）」を中心に疎結合なコードの書き方がま
とまった章です。

DI は正直今までピンと来ていませんでしたが、この章を読んで完璧に理
解しました。10 年前から使っていました…。

数日経ってもまだ何か言ってる。


P80
自身より変更されないものに依存しなさい

この章はこれに尽きると思います。

第４章 柔軟なインターフェイスを作る

P104
　仮にオブジェクトが人間だとして、自身の関係を説明できるとしましょ
う。すると、図4.5では、Trip は Mechanic に「私は自分が何を望んでい
るかを知っているし、あなたがそれをどのようにやるかも知っているよ」
と伝えているはずです。（中略）
　**この手放しの信頼が、オブジェクト指向設計の要です。**これによって、
オブジェクトは自身をコンテキストに縛り付けることなく、共同作業でき
るようになります。また、これは成長し、変化することが期待されるアプ
リケーションには必要不可欠です。
（太字は引用者によるもの）

これを読んで、なぜかアジャイルについて腑に落ちました。理解するのに
何年かかっているんだよ…。

※ アジャイルはオブジェクト指向を人に置き換えたもの

第６章 継承によって振る舞いを獲得する

業務でサブクラスが super にメッセージを送るコードを頻繁に見かけま
す。P172 にこのリファクタリング方法が書かれていました。

やり方は簡単で、post_initialize のようなフックメッセージを用意する
だけ。そうすることで、サブクラスは必ず super を呼ぶ責任から逃れら
れます。「いつ」初期化が行われるか知らなくてよいのは大きい。結合度
の低減です。

最近は継承をなるべく使わず、委譲を使うことを意識していますが、継承
もちょっとしたテクニックで結合度を減らせることを学びました。

第７章 モジュールでロールの振る舞いを共有する

P202 に「リスコフの置換原則（LSP）」が書かれていました。

システムが正常であるためには、派生型は、上位型と置換可能でなけれ
ばならない

正直知らなかったのですが、これに限らずこの本には法則がいくつか出て
くるので、そもそもの知識として身に付けたいと思います。

第８章 コンポジションでオブジェクトを組み合わせる

P231
したがって、継承では、「自分が間違っているとき、何が起こるだろう」
という問いかけが特別に重要な意味を帯びてきます。

さきほどの super の話もそうですが、継承はただでさえ強い結合なので、
修正の影響を少しでも減らさなくてはいけません。

第９章 費用対効果の高いテストを設計する

テストには多少自信があったのですが、この章を最初読んだ時、少々落ち
込みました。

P260 のようにスタブ前提のテストが奨励されており、今までの私の書き
方とはある意味真逆だったからです。

P261
アプリケーションがはっきりと間違っているにもかかわらず、テストはの
んきに、すべてうまくいっていると報告します。このような世界をつくっ
てしまう可能性があるゆえに、スタブ（とモック）はテストを脆くすると
警告する人がいるのです。

わたしです。^o^

でも読んでいて、DI などで疎に設計されたアプリケーション前提なのか
も？と思い直しました。密結合で使うのはなかなか危険かも。

とは言え、今後は少し考えを切り替えようと思いました。

以下は雑多な疑問や感想。

P272 では危険を承知でテストを書く前にリファクタリングをしているけ
ど、やらないほうが良いと思いました。

P279 はスタブ前提でも壊れづらいテストの書き方です。テストの
respond_to ってこういう時に使うのね。private メソッドを呼んでいる
かのテストは見たことがある…。

P290 では抽象スーパークラスもテストをしていました。私は今まで書か
ないようにしていましたが、前述の「リスコフの置換原則」に沿った設計
をしていれば、テスト可能という話です。

この章のテストは MiniTest で書かれているので、RSpec で書いてみよう
としましたが、GitHub にいくつかあった のでそれを読んで満足しました。