はじめに
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 を読みました。
この本は、オブジェクト指向の設計について、Rubyのプログラムをサンプルに、分かりやすく解説されています。
設計について学びたいRubyエンジニアにおすすめできます。
これを学ぶことで、変更しやすい、メンテナンス性の高いコードを書くための考え方が身につけられます。
メンテナンス性の高いコードを書きたいと思っているRubyエンジニアは、個人的には、リーダブルコードの次に読むべき本だなと感じました。 (リーダブルなコードについては前提として知っておいたほうがいいです)
どうしてこの本を読んだのか
クラスの設計、インターフェースの設計に苦手意識を持っており、元々社内でも多くの人がおすすめしている本だったので、読んでみようと思いました。
今まで、インターフェースを使ったオブジェクト指向の言語をあまりきちんと使ってきたことがありませんでした。そして、ある実装のレビューで、インターフェースがいまいちというコメントをもらったとき、きちんと腹落ちできていないことがありました。
「インターフェース」が存在しないRubyにおいて、インターフェースをどのように考えて、どうクラスを設計するのかを学びたいと思い、この本を読みました。
デザインパターンについて学ぶことも検討したのですが、先にコアとなる設計の概念を学んでから、実装のパターンを学びたいと思ったので、また次にしようと決めました。
目次
第1章 オブジェクト指向設計
第2章 単一責任のクラスを設計する
第3章 依存関係を管理する
第4章 柔軟なインターフェースをつくる
第5章 ダックタイピングでコストを削減する
第6章 継承によって振る舞いを獲得する
第7章 モジュールでロールの振る舞いを共有する
第8章 コンポジションでオブジェクトを組み合わせる
第9章 費用対効果の高いテストを設計する
感想、学び
- 「世界を、オブジェクト間の自発的な相互作用」という観点で捉える意味が、本を読んで理解が深まった
- 相手のオブジェクトに対して、何をしてほしいのかのメッセージを送るが、どのようにしてほしいかという手順は知らなくていい
- 生み出す利益と、実現するためのコストを比較。この変更コストを下げるようにする。というのがシンプルでわかりやすかった
- 設計ができないことはプログラミングの抑止力にならない。後々の変更で苦しむという部分から、「設計が大事」と実感するときにはすでに遅く、効果が聞くまでに時間がかかることを感じた
- 「振る舞いに依存する」というのは、オブジェクト間だけでなく、オブジェクト内でも当てはまるという学び
- インスタンス変数というデータではなく、アクセサメソッドを使う
- 別クラスとして切り出すべきか悩むのであれば、将来切り出せるように単一責任のメソッドとして実装するという方法もあること
- 「依存する」の理解がはっきりした。以下を知っていること
- 「他のクラスの名前」「メッセージの種類(メソッド名等)」「メッセージが要求する引数」「引数の順番」
- メソッドを呼び出した時点で、それに依存しているという点がスッキリした
- クラスのインターフェースを決める時、そのクラスが「何をするか」ではなく、「何をpublicにするか」を決める
- publicなメソッドはそのクラスがどう振る舞うのか、責任を明らかにするもの
- オブジェクトがどんなpublicメソッドを持っているかという抽象化したものがインターフェースとなる
- そこに、他者が依存をする
- ダックタイプも、このインターフェースに依存している
- 逆に呼び出す側は、どういうメッセージを呼び出したいか。「どのように」ではなく「何を」を頼む
- そして、誰がそれに応答すべきか
- Moduleを、共通部分の切り出しくらいの意味合いで使っていたが、「ロールとして振る舞いを定義し、mixinしたクラスがそのロールを担う」ということができる
- 今まで知らずにそのように実装していたが、明確に意味づけができるようになった
- 同じモジュールをincludeしているオブジェクト同士は、同じインターフェースを実装しているので、入れ替えが可能になる
- includeをすると、そのModuleが定義するパブリックインターフェースを持つことになるというのが発見だった
- この抽象的なロールは具象よりも安定している
- コンポジションを使って、大きいオブジェクトを、小さい部品で組み立てる
- 言語化していなかったけど、DDDの値オブジェクトとかもこれの一種なのかなと繋がった
- コンポジションを使うと、シンプルで利用性が高いオブジェクトを組み合わせて作っていける
- 部品は理解しやすいが、組み合わされた全体は理解しやすいとは言えないこともある
- 設計をしっかりすると、全体像が理解しづらくなるのは感じたことがあり、どちらに重きを置くかというところなのかなと感じた
- プライベートメソッドを持ちすぎたクラスは、責任を大量に持ちすぎている可能性がある
全体を通して
- 「設計」の苦手意識について考えていたが、「読みやすいコード」、「設計」、「アーキテクチャ」と、どれも重複する内容があり、どこが苦手なのかのマッピングが難しいと感じた
- この本も設計の話でありながら、実装の詳細にも触れられていたりする
- 自分はちょうどインターフェースの「設計」の部分が刺さったが、人によっては違うので、目次等を見ながら身につけたいところを探ったほうが良さそう
- 他にも、手続き or オブジェクト指向、DDD、プログラミングの原理、原則、Rubyのスタイルガイド等関連するところはあるので、人によってどこからやるのかが違うのかもしれない