【書評】『オブジェクト指向設計実践ガイド』

総評

★★★★★

オブジェクト指向を用いた設計の勘所を書いた本。
正直、今まで読んだオブジェクト指向について本の中でもピカイチ。
オブジェクト指向を、概念的に捉えている人にぜひとも読んで欲しい本。
時々Qiitaとかに謎のオブジェクト指向ポエムが流れてくるが、 そんなの読んでる暇あったらこれを読んだ方がよい。
コード例とともに、どうしたら良い設計ができるのか、わかりやすく解説されている。
オブジェクトそのものやデザインパターンというよりか、どのようにメッセージや依存関係を管理するかに主眼が置かれている。

感想

以下、章毎にまとめ

  • 第1章 オブジェクト指向設計
  • 第2章 単一責任のクラスを設計する
  • 第3章 依存関係を管理する(以下、TBW)
  • 第4章 柔軟なインターフェースをつくる
  • 第5章 ダックタイピングでコストを削減する
  • 第6章 継承によって振る舞いを獲得する
  • 第7章 モジュールでロールの振る舞いを共有する
  • 第8章 コンポジションでオブジェクトを組み合わせる
  • 第9章 費用対効果の高いテストを設計する

第1章 オブジェクト指向設計

設計をする目的は、変更を容易にするため。
オブジェクト指向設計とは、「依存関係を管理すること」」(p. 19)
設計が悪いと一つの変更は他のプログラムに伝播し続けていき、一つを変更するとそれに関係するオブジェクトすべてに被害をもたらす。

設計の原則

SOLID

  • 単一責任(Single Responsibility)
  • オープン・クローズド(Open-Closed)
  • リスコフの置換(Liskov Substitution)
  • インターフェースの分離(Interface Segregation)
  • 依存性逆転(Dependancy Inversion)

DRY

Don't Repeat Yourself

デメテルの法則

Low of Demeter

これらの原則を本書全体で扱っていく。

設計の能力のないプログラマー「はい、その機能は追加できますが、『すべてが壊れます』」 不必要に設計するプログラマー「いいえ、その機能は追加できません。『それをやるための設計はしていません』」

アジャイルの必要とする設計は、事前に完璧な詳細設計(BUFD : Big Up Front Design)を作ることではなく、
変更に強い適応性と柔軟性があるコードを作ること。

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

クラスはどのように設計するべきか。
=>変更がかんたんな用にコードを組む

そのためには以下の性質(TRUE)が必要。 - 透過性(Tranceparent):変更がもたらす影響が明白 - 合理性(Reasonable):変更のコストは利益にふさわしい - 可用性(Usable):元々予期しない環境でも再利用できる - 模範性(Examplary):変更を加える人が、上記の品質を自然と保つコードになる

TRUEを達成するための一歩が単一責任原則

以下、自転車とギアの例でコードを交えて解説。
Gearクラスがある場合に、そのクラスはどこまで情報を知るべきなのか。

クラスが単一責任か見分け方。
データではなく、振る舞いに依存させる。
複雑なデータ構造の隠蔽。
メソッドレベルでも単一責任原則を当てはめる。
責任の隔離。

第3章

以降はまた時間のある時に書く。

次に読む本

オブジェクト指向についてもっとしるなら。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

デザインパターンを知るのもオブジェクト指向の勉強になるし、現実的なプログラミングでもかなり有用。 増補改訂版Java言語で学ぶデザインパターン入門