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

今更ながら読んだ。

書いてる内容は今の自分にとってはふんふんそうだよね。という感じ。 以下、思った点

単一責任の原則

2章でほぼすべて言いたいことは言っている感じ ここで言われている単一責任の原則はオブジェクト指向というよりプログラミングの大原則なのに、1つのクラスで色々やろうとしすぎる人が多すぎる。 本書で言う所の第4章P105あたりで TripFinder を導入するくだり。この選択をできない人は依存度が高いクラスを作りがちになると思う。

特にRailsからプログラミング始めた人は、テーブルと対になっているModelクラス以外にドメインロジックを持ったクラスを作ってはいけないと思い込んでしまう傾向があるように感じる。 こう書くとなんでもかんでも別クラスにしたがる輩が量産されそうなのでこの記事も忘れずに参照されたし。

継承

Rubyで継承を使った方がいい場面ってほとんどなくて、8割型mix-inとダックタイピングで済む話な気がしている。 というのも、僕が見てきた継承が使われているコードはほぼ全てメソッドを共有するために使われているからだ。 あとRailsで継承というと切っては離せないのがSTI。STIについて話すと長くなるので割愛するが、あとで type == 'hoge' なんて書くくらいならSTIを使うべきではないと思っている。 しかし、8章にある

次のようなフレームワークを書くのは避けなければなりません。ユーザーがその振る舞いを手に入れるために、フレームワークのオブジェクトを継承しなければならないようなフレームワークです

という文章は大丈夫なのかｗ みんな大好きActiveなんちゃらがそうだから、みんなほげふがBaseを作って継承させるライブラリを喜々として作っている気がするｗ

ダックタイピング

if文でクラスをチェックしている（もしくはそれに類似する）コードは本当によく見かける。 そういうケースは大体ダックタイピングをちゃんと理解できていない。 本書を読めばダックタイピングというものがとても良く理解できると思う。

テスト

最後のテストの章が意外と大切だと思った。 基本的にテストが書きづらいクラス/メソッドは設計が間違っているパターンが多い。 最近、簡単な処理のテストを書きたいだけなのにあれこれ準備しなきゃテストできない事象に頭を悩ませている。 これは明らかにクラス間の依存度が高すぎるから引き起こされている事象だし、テストを書くことでこれらの問題に最初から気づくことができたはず。 テストがない環境で作られるものは設計がまずいケースが多い気もする。 みんな、テストちゃんと書こう

これからRubyで何か書こうとしている人って言うより、半年〜1年くらい既にRailsを使った開発PJに関わっている人とか、2年くらい運用されたRailsアプリをリファクタしなきゃいけない人とかが読むのがちょうど良い気がする。

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