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

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

作者: Sandi Metz,?山泰基
出版社/メーカー: 技術評論社
発売日: 2016/09/02
メディア: 大型本
この商品を含むブログ (1件) を見る

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

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

Effective Ruby は Ruby 力をあげる本、リファクタリング 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