読者です 読者をやめる 読者になる 読者になる

雀巽の日記帳

雀巽が綴る日常の記録

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

オブジェクト指向設計実践ガイド Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」を読みました。

端的に言うと、めっちゃ良かったです!

これは良書だー!って感じでガツガツ読み進めました。

Effective RubyRuby 力をあげる本、リファクタリング Ruby エディションはリファクタリング力をあげる本(というかリファレンス)という感じでしたが、こちらは純粋にオブジェクト指向設計力をあげる本という感じでした。

オブジェクト指向プログラミングに触れた早い段階で読んでおくと、良いんじゃないかと思います。

以下、印象に残っているところを抜き出してみます。

SOLID

オブジェクト指向設計で最もよく知られている5つの原則の頭文字です。

  • Single Responsibility
  • Open-Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

TRUE

変更が簡単なコードが持つべき4つの性質の頭文字です。

  • Transparent
  • Reasonable
  • Usable
  • Exemplary

TRUE の第一歩は単一責任原則とのことです。

個人的には「単一責任原則 (Single Responsibility Principle)」は名前付けとも大きく関わっていると思います。

クラス、メソッド、変数などに「適切な名前がつけれない」ときは、責任が一言で説明できないときであり、この原則に違反している場合が多いです。

オブジェクト指向設計とは「依存関係を管理すること」

いかに依存関係を整理し、変更しやすく保つか、というのがオブジェクト指向で設計する意味、だと思います。

アジャイルが有効である理由は、ソフトウェアがかたちになる「前」に確かさを手に入れることはできないと認めたから

建築に例えられることは多いですが、建築との違いの一つは「正確な模型」が容易には作れないことかなと感じます。

かたちになる「前」に確かさを手に入れられない、というのは、ソフトウェア開発の難しさの一つですね。

第一にやるべきことは、深呼吸をして「シンプルであれと主張すること」

パターンを学んだばかりの人が陥るとされる「間違った問題に対してパターンを適用する」みたいな事例を思い出しました。

KISS の原則を思い出しましょう。

メッセージに基づく視点は、クラスに基づく視点よりも柔軟なアプリケーションを生み出す

メッセージがオブジェクト指向の本質だよと伝わってくるメッセージです。

オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する

という文や、

オブジェクトを関連づけるのは、それが何をするかではなく、その間で交わされるメッセージ

という文もあり、メッセージパッシングこそがオブジェクト指向!というのが伝わってきます。

シーケンス図を利用すると、設計の議論がメッセージ中心となる

メッセージが大事なので、メッセージ視点になれるシーケンス図を使おうという話でした。

ホワイトボードに描き、必要に応じて変更し、その目的を果たしたら消す

これくらい軽い気持ちで書けばいいんだよ!と言うアドバイスも印象的でした。良い。

新たな継承の階層構造へとリファクタリングをする際は、抽象を昇格できるようにコードを構成すべきであり、具象を降格するような構成にはすべきではない

具体的には、スーパークラスにサブクラスの情報が残るおそれがあるので、一旦具象クラスにすべて置き、確実に抽象(共通)だと言えるものをスーパークラスにあげる、ということです。

直面した問題がコンポジションによって解決できるものであれば、まずはコンポジションで解決することを優先するべき

かつて「継承は最終手段」とも聞いたことがあるのですが、それを思い出しました。

使われていないコードは、復旧するより残し続けるコストのほうが高い

汚物は消毒だー!

プライベートメソッドを大量に持つオブジェクトからは、責任を大量に持ちすぎた設計の臭いが漂う

コードの臭いです。コードの臭いを嗅ぎ取れるようになるのはすごく重要です。

そうするのが適切な問題であれば、恥ずかしいコードを書くことに自信を持つ

以下、少し長めに引用します。

短い期間で、かつ、そうするのが適切な問題であれば、恥ずかしいコードを書くことに自信を持つことで、資金を節約できます。 設計の決定を遅らせることが目的であるときは、今ある問題を解くために一番シンプルなことをやりましょう。 めちゃくちゃなコードは、考えられ得る限り最善のインターフェースの背後に隔離し、あとはもっと情報が来るまで、じっと待ちましょう。

これ、とてもいい話だなと思います。

完璧ではなく、現時点での最適を目指す、という基本を守っていれば、状況によってはこういうこともありますよね。

この本の作者と関連のある、以下の良記事を思い出しました。

18f.gsa.gov

おわりに

オブジェクト指向設計実践ガイドというタイトルどおり、非常に実践的なガイドだったと思います。

オブジェクト指向で設計する、というのがどういうことなのかが伝わってくる本です。

また、テストの章もしっかりと書かれていて、とても参考になりました。

ダックタイプやテストダブルを使う際のダブルのインターフェースのテストとそれの共有、これまで全然やってなかった気がするので、今後活用したいです。

これと合わせて、デザインパターン本を読んでおくと更に理解が深まり良いと思います。

necojackarc.hatenablog.com

現実世界の複雑さと変わりやすさを適切な設計で乗り越えていきましょー!