オブジェクト指向設計実践ガイドを読んだので感想１
オブジェクト指向設計実践ガイドを読みました。 結構難しい本だった気がします。最初は翻訳が分かりづらいとか散々文句言ってましたが、単に知識がないだけだった気がします。反省。
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 | 成瀬 允宣 | コンピュータ・IT | Kindleストア | Amazon
最初はよく分かっていなかったんですが、 このあたりの本を読んでオブジェクト指向設計がデータと振る舞いの持たせ方を定義し、それぞれのオブジェクトがどのようにメッセージをやり取りし合うことで依存関係を構築するかを設計する行為だと分かった上で読んだらスラスラ分かるようになりました。とは言っても上の二冊も簡単な本ではなく、知識の結びつきで簡単に読めるようになっただけだとは思います。
オブジェクト指向設計では、このようにお互いがお互いを知っており、どのように呼び出すかを知っている状況を好ましくない状況とし、
このように単方向に自分が呼び出すべき相手を知っていることを好ましい状況として定義して、 これをどうやって実現するかを考えていく必要があるわけです。
変更が起こりうる部分を特定し、図でいうとrootのオブジェクトはあまり変更が発生しないオブジェクトを配置し、 leafの部分の方に変更の発生しうるオブジェクトを配置することで、変更時の対応がしやすくなります。
小さいソフトウェアであれば依存関係がゴチャゴチャであっても気合でなんとかしたり、自分が知ってさえすればそれで何とかなるのですが、 ある程度規模のあるソフトウェアになると、オブジェクトを入れ替えたり修正したいときなどに、お互いがお互いに依存して密結合になり、変更不可能になる部分が出てきてしまうため、 修正が困難になってしまいます。また、後々関わったプログラマは設計当時の状況を知らないので、オブジェクトを好き勝手に使ってメチャクチャにしてしまう可能性があるため、設計により、使用方法に制限を加えなければいけません。
そのための方法論が書いてあります。(今度まとめる
- is-a
- has-a
- behave like
に着目してそれぞれ継承、委譲、モジュールインクルードを使い分けることが重要です。
可能な限り委譲を使用し、継承はあまり使わないことが必要です。
今後調べる必要がある部分としては、 Rubyの場合は静的型ではなく、InterfaceやAbstract Classも存在していないので、JavaやC#との違いを深堀りしたい。
