最初にオススメポイントだけ書いておく。この本には

• テスト容易性の確保
• 複雑性保存の法則への対処

へのヒントが詰まっている。

kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。

読み手に推奨される準備

まずはじめに「本書の読者対象」を挙げておくと、

本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。

と書かれている。

正直に告白すると自分はこれをなめていた。普通に UML もデザインパターンも出てくる。もっとも、この本に出てくる図は十分に簡単だし最低限の説明はなされている。またデザインパターンもインターフェイスに注目してごくわずかしか出てこない。なんだけど、覚悟しておくのとしていないのとでは雲泥の差。早めに覚悟しておこう。UML もデザインパターンも普通に出てくるよ。

あと前提知識としては当然 Java 的な意味での interface（PHP 5 以降にもあるね）、あるいは Ruby で言う Module がどういうものか分かっていないとつらい。それに継承の問題について自覚的であった方がよい。継承がいかに扱いにくいかを普段感じていないと、サンプルのコードだけではいたずらに複雑になっただけに感じられてしまう。丁寧に書かれているんだけど、問題意識がなければたぶん通じないんじゃないかな¹。

内容

I部、特に3章と4章では本書で扱うインターフェイスに関する用語が怒濤の勢いで出てくる。リファレンス的な部分。その前の2章で契約というキーワードでインターフェイスを考えるための材料が整理されている。

またこの中でさりげなくだけど何度もインターフェイスの変換について触れられている。これはのちのち効いてくる。

5章ではポリモーフィズムを継承ではなくインターフェイスを使って実際に組み立てていく。Role を使ってフットボールチームの話をしているうちはよかったんだけど、Java の InputStream に縁のない自分はちょっとこの辺で意識が飛んでしまった。

II部では開発を進める段取りと実際の作成。7章でインターフェイスに注目しながらユースケースを作り、それをテストしようと試みる、IRI カードなどの話。メソッドが明確になったら実際にテストコードが出てくる。8,9,10章は動くものの話。内容的には Web 系が中心でなじみやすい印象。

最後 11 章でインターフェイス指向からパターンをおさらいして終了。

感想

一言で言うと素晴らしくオライリーらしい。歯ごたえたっぷり。悪く言えばもっと内容を噛み砕いてほしかった。噛み砕く手間と分量で値段は上がってしまうだろうけど、この本は例え1000円高くなっても3600円。十分通用するんじゃないかなぁ。オライリーだし。

実際のところ特別難しいわけじゃないと思うんだけど、個人的な好みはもっと図やサンプルを多くしてほしいんだな。自分は言葉だけでは覚えられないタイプで、何かしら頭の中にビジュアルやアニメーションが思い浮かべないとダメなんで、それを用意しておいてくれるととても嬉しい。いやユースケースやシーケンス図や IRI カードは出てくるんだけど、なんかそういうものじゃないんだなぁ。うまい言葉が見つからない。

なんていうか結構いろんな説明がサラッと出てきていて、もったいないなぁと感じる部分がちらほらあった。ここは重点的に説明しようと感じられたのは「継承とインターフェイス」の部分くらいで、あとは「ま、フツーに知ってるよね？」的な印象。Dependency Injection なんか「あるいは Dependency Injection パターンを用いて実装を設定できます。」とか「おいおい、それだけ？」みたいな。実際のコード間のインターフェイスをどう作り上げていくか、すごく大事な部分のような気がするんだけど、その辺はインターフェイスに注目して分析、設計していく過程としてはあまり重視されていないのかしら。それともやはり使えて当然か²。そういう意味では経験で補いながら、手を動かしながら読む感じ。例えば DOM と SAX の違いってサンプルコードだけで分かるのかな。自分は幸い両方経験があったからすんなり分かったけど、そうでない場合は一つ一つ噛み砕くのにそれなりに時間掛かるんじゃないかな³。

あと当然なんだけどインターフェイスという言葉がたくさん出てきてその意味が文脈によって変わるので、特に前半の説明の部分でなかなか頭の痛い思いをさせられた。より一般的な常識的な意味でのインターフェイスであったり、ある程度の機能のまとまりを意味していたり、Java用語的な Interface を意味していたりする。その使い方をいくつかに分類して、ここではこういう意味、ここではこういう意味と、例えば type face を変えるなどして明確にできていたらこれはかなり画期的な本になっていたのではないかと思う。

なんだろう、この出だしの滑らかさとは裏腹にいきなり歯ごたえたっぷりな内容に移行する感じ、覚えがある…と思っていたら、読み終える直前に気づいた。

この本、『プレファクタリング』の人が書いてた。

実はわたくしこの『プレファクタリング ―リファクタリング軽減のための新設計 (THEORY/IN/PRACTICE)』、途中で挫折しております⁴。いちばんの理由は Java のコードを読むのがたるいというものなんだけど、今回も終盤はその呪いを解くことはできなかった。だいぶ端折ってしまった。疑似コードもあんまり読みやすい気がしなかったけど、これはオレのセンスがないのかなぁ。内容はいいと思うんだ、内容は。

オライリーの本て、なんかそういうとこあるよね。⁵

ただ思いっきり自分の言葉で要約すると

• テスト容易性の確保
• 複雑性保存の法則への対処

へのヒントは確実に詰まっていると思う。高凝集、疎結合という言葉が帯にはあるんだけど、自分としては上の二つの言葉の方が断然しっくりくる。この視点で振り返ると、インターフェイスの変換の話がいくつも出てくるのは実はこのためかと気づく。

オススメと言えばオススメ。でもコレ読むとすごくよく分かるよ！新しい発見があるよ！という意味ではなく、これは通過しておくべき、という意味なのかなぁ。さらっと読めば読めちゃうと思うんだけど、さらっと読んじゃダメというか。たぶん自分はこの先何回もこの本を開き直すと思う。API を使ってゴニョゴニョとかするときにもそのインターフェイスの意味、機能、他のインターフェイスへの変換などのヒントになると思うから。

とりあえず今度もう一回『プレファクタリング』に挑戦してみる。今見直したらプレファクタリングにもインターフェイスの話出てくる。あー、今読めばイケるかもな、これ。コード全体を変更に強くする、どちらかというと実装のためには『プレファクタリング』を、分析、設計のためには『インターフェイス指向設計』を読むのがいいみたい。まさに合わせて読みたい。

あとちゃんと『新装版　リファクタリング　既存のコードを安全に改善する』と『達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 (Ascii software engineering series)』も読んだ方がやっぱいいんだよね？ （実はちゃんと読んだことがない。）

直接関係しないんだけど、PHP 5 で interface が入ったじゃないですか。でも名前空間は相変わらずないんですよ。なんか interface の機能はいいんだろうけど、名前争奪戦が激しくなるだけなんじゃないの？という印象を持ちました。やっぱまだロジックは Ruby で書いてテンプレートを PHP で書くのが最強という印象は変わらないなぁ。