kenju's blog

About Programming and Mathematics

『オブジェクト指向設計実践ガイド』を読んだ

設計力って難しくて面白い。日々そんなことを感じながら広告配信サーバーの設計だったり自分で作っているライブラリの設計だったりを毎日プログラマとしてしているわけで、設計力は徹夜で身につくものではなく、失敗を含めた幅の広い経験を積まないとなかなか一流にはなれないと感じている今日この頃。

とはいえ、数打てば当たるで猪突猛進に進むのではなく、ある程度の方向性と知識を持った上で進まないと、寄り道ばかりしてしまう。そんなことを考えていた時に、

という意味で、今の自分にぴったりな書籍が、この本だった。存在は知ってはいたものの、積読状態だったが、先月・今月あたりで読み終えた。

「単一責任のクラスを作る」とか、「インターフェースから考える」とか、「依存関係は可能な限り取り除く」とか、言うのは簡単だけどそれらを呼吸するように設計できているかと言うと、それはまた別の話。

「ダックタイピング」とか「Module を利用した振る舞いに着目した設計」とか、Ruby の言語特性を活かしたオブジェクト指向設計のプラクティカルな事例を見ることができたのは、非常に学びが多かった。

印象に残っている箇所

本書の所々に印象に残る格言が散りばめられていて、アーキテクトの目線でとらえたアプリケーションの設計を垣間見ることができる。

少し知識を得たころこそ危険なのです。知識が増え、その見返りを求めるようになり、執拗に設計するようになってしまいます。情熱のあまり、不適切な場所に原則を適用し、存在しないところにパターンを見出すのです。(p.25)

これにはどきっとさせられた。『オブジェクト指向入門 第2版 原則・コンセプト』を読んだ時もそうだったけど、デメテルの法則〜とか、SOLID〜とか、デザインパターン〜とか、"知識"を得た途端、身の回りのものがそれまでとは違った見方で見えてくる、というのが学びの一般的な醍醐味ではある。しかし、それを適用したいがために、現実を歪曲してまでその適用事例やパターンを見出しかねない。知識は現象を正しく分析するための手段であって、それ自体が目的であってはならないと、気づかされる一言だったり。

「今日何もしないことの、将来的なコストはどれだけだろう?」(p. 44)

実装していると、リファクタリングしたいところなんぞ山ほど出てくる。それが2008年がinitial commitのレポジトリとかだったりすると、過去のレガシーが至る所にあって手を出したいところだらけ。

しかし、本当に今自分が見ている箇所は今リファクタすべきなのだろうか、今コストをかけて再設計すべきなのかどうか、自分が見逃している挙動や例外パターンはないか、そう言ったことを冷静に判断しないと、ただただ目に見えたゴミを拾う計画性のない Junior Software Engineer にすぎないのだなと、気づかされる。

基本的な設計の質問を、「このクラスが必要なのは知っているけれど、これは何をすべきなんだろう」から、「このメッセージを送る必要があるけれど、だれが応答すべきなんだろう」へ変えることが、キャリア転向への第一歩です。オブジェクトが存在するからメッセージを送るのではありません。メッセージを送るためにオブジェクトは存在するのです。(p.97)

本書で一番目からウロコが落ちた箇所といえば、ここ。まさに自分はいつもクラスから考えると言うか、すでにクラスがそこらへんうようよしていてお互いのコミュニケーション方法を探っているようなイメージだった。だけど、そもそもそこにはどのようなコミュニケーションが発生すべきなのか、そのために呼ぶべきオブジェクトは誰なのか、という発想の転換はなかった。関係ない人をとりあえず良さそうだからとミーティングに呼んでみたけど議論が発散して終わるのと、ミーティングのゴールとアジェンダを決めた上で適切なロールを持った人物をミーティングに呼んで議論が収束して終わるのと、といった違いだろうか。

最後に

とまあ、色々今の自分にとって学びの多い一冊だった。もっと早くに読んでおけばよかったと思っている。

そのほかにも、Tipsレベルで、DIを利用した依存性の抽出方法だとか、ダックタイピングの振る舞いに着目したテスト手法だとかが学べる意味で、本自体がプラクティカルさ(具体性)と知識(抽象性)が絶妙なバランスで「設計」された良書だと言えるだろう。読んでよかった。