『オブジェクト指向設計実践ガイド』読書会での感想メモ
6/1 から 8/24 まで、フィードフォース社内で『オブジェクト指向設計実 践ガイド』の読書会を主催しました。 loading... ↑ これはブログ記事に使うための先行 Tweet でした。やっと使えたw 都度メモを取って会社の Slack channel に書いていたのですが、公開の タイミングを逃して後悔していました。そんな折、kano-e さんが会社の 新生開発者ブログに記事をポスト。 空気を読まずに私もポストします。個人ブログに。本当に五月雨式のメモ で自分向けです。 第1章 オブジェクト指向設計 まだ意識が高まっておらず、感想を書いていなかった。プロローグ的な章。 第2章 単一責任のクラスを設計する これらが当たり前に出来るスキルが必要だと思った。 健康的な書き方をほかのプログラマーに促進するコードを書く atter_reader 等を介して、複雑か簡単かどうかさえも見せないように 隠蔽する リファクタリングでメソッドへの切り出しをすることで、クラスの責務 を明確にする 決断を先延ばしにする 第3章 依存関係を管理する DI 初登場!! 第3章は P19 の『オブジェクト指向設計とは、「依存関係を管理する こと」です。』を具体的に説明した章 とにかく依存関係を減らすことが重要 DI メソッドでキーワード引数を使うことで、パラメータの順序依存をなくす ファクトリパターンを使った外部インターフェイスのラッピング あまりに複雑だと、ラッピングしすぎないほうが良いことも 自身より変更しないものに依存しなさい Ruby にはインターフェイスがないので、エンジニアのスキルがな いと振る舞いに気づかないことも 本質的に抽象はより安定 Jpeg, Png, Gif などより、Image といった抽象度を高めたオブジェ クトのほうが変更されづらい 第4章 柔軟なインターフェイスをつくる ◆ P102 の図は少し煙に巻かれた気がした “#prepare_trip” に self を渡す発想はなかった でも、self には “.bicycles” という振る舞いが必要だから、bicycles をそのまま渡せば良いのでは? CarMechanic class とか登場したら、 “....