インターフェイス指向設計を読んで

はじめに

たまたまタイムラインを眺めていたら、ちょうど監訳者の角谷さんがtwitterで献本先を募集してたので、手を上げたらいただけてしまいました。

ホントーにありがとうございます。

で、会社の行きかえりの短い時間を積み重ねて、おとといやっと読了しましたので、感想などを書いてみたいと思います。

どんな本？

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

こんな本。

ぱっと見

表紙がちょっと古い感じがするなぁと思ってたら、著者が自慢げに表紙について書いてるのを見て心を入れ替えました。
正直スマンかった。

全体についての所感

ある設計方式のトレードオフについて、簡潔にまとめられてるのがいいですね。
全員が同意できる内容ではないところもあるかと思いますが、割と公平な感じで書かれていたかと思います。

しかし、常にフェアな記述をモットーとする(と勝手に決めつけてる)著者なので、コード例とかもできるだけ言語にとらわれずに書こうということで、オリジナル(?)の擬似コードで説明してるのですが、その記法については全く触れられてません(よね？多分)。

しかも、フォーマットとか変態すぎ(よくない方の意味で。
変態すぎてインデントがくずれてることに書いてるほうも気づけないという恐ろしいワナがｗｗ*1。

今回の読み方

さて、今回は付箋を用意しておいて、気になった箇所にペシペシはっていく方式で読んでいきました。
最終的にそこから抽出して、こういう風にまとめたりなどしてみたり。
いつもはサラっと流し読みしたりするんですが、なにぶん始めての(強引にいただいた)献本なので気合が入ってみたり。

感銘をうけたところ

さて、その中で自分として面白いなぁとか、オッとか思ったところを抜き出してみます。
抜き出しただけなので説明不足な点はご容赦ください。基本的に自分用のメモな雰囲気で。

P.24 脚注「インターフェイスの機能を分離させることによって、1つのインターフェイスが持つ状態遷移の数を減らすことができ、エラーの発生率を低く抑えることができます。」

分割して統治せよ、ですね。

P.40 脚注「コレクションインターフェイスのプッシュ/プルのスタイルを内部イテレータと外部イテレータとして説明しています。」

ああ、わかりやすい見方ですね。
「コレクションインタフェースのプッシュ/プル」って何よ？ってのはぜひぜひ本書にあたりましょう。

P.61 脚注 (引用は省略)

文法上のダウンキャストを意味的に2つに分類しています。1つは基底クラスから派生クラスへのキャスト。もう1つはインターフェイスへのキャスト。そして、筆者は後者についてはダウンキャストではないため問題ないとしています。

確かに、インターフェイスへのキャストは、APIの一部を抽出して他の余計なメソッド/フィールドへのアクセスを隠蔽するぐらいの意味で、派生クラスへのキャストと比べるとそんなに悪いことはないようにも思えますが、実際のところコード上の記法は同じであり、キャスト文法自体を使うのが好ましくないなぁと個人的に感じます。
Java5のGenericsに侵された脳としては特に。

Generics使えば、どちらの意味であれ、実質ダウンキャストはほぼ99%ユーザコード上から消せるのではないですかね(いいすぎ？)。
どうしても消せない部分は、ユーティリティクラスなどで対応すればカプセル化できそうな気がしますし。

P.67 「複雑性保存の法則」

これは良い言葉！

P.70 脚注 (引用は省略)

インターフェイスは多くの場合形容詞的な名前になるので「A is B」と書ける。
だけどこれじゃ継承(is-a)と混同しやすい。
「A provides-a B」と読み替えれればそれはインターフェイスと実装の関係である、と考えればOk。
と読みました。

P.94 (引用は省略)

WWW(HTTP。RESTも含む)は、ドキュメント型インターフェイスと分類されるのか。なるほどなるほど。

P.147 「テストは特定の実装ではなくインターフェイスに対して作成する。そうすることで、テストは再利用しやすくなる。」

なるほどー。
今までは、実装単位でホワイトボックステストを書いてしまってました。HogeImplTestみたいな。
ホワイトボックス指向なんでしょうかね。
「この世に不思議なことなど何一つ無いのだよ」的な。

でも、資産価値が高いのは確かにインタフェースに対するテストだと思います。

基本的にインターフェイスに対してテストを書いて、そこでカバーできないような内部的でかつ複雑なロジックがあれば、テストクラスを分ける形で別途実装クラス用のユニットテストをつくればいいのかなぁ。

P.189 PROXYの長所が「機能(セキュリティ、ログ)を透過的に追加できる。」

それなんてAOP? と思ったら、確かに初期のSeasar2は、動的Proxyを使ってAOPを実現していたと聞いたような記憶が・・・。

読みどころ

監訳者まえがき、と、脚注。
特に、今回脚注が面白いと思いました。

まとめ

一度じっくりと読み込んだ後は、設計で迷ったときの道しるべとして、リファレンス的に使えそうです。

一家に一冊、常備しておくといざというときに安心ですね(?)。

*1:翻訳時に入ったエラーだとしても、それはある意味必然的にうまれたエラーな気がします。だってあのフォーマットはないわーーーーー