さて、ゴールデンウィークです。

休みがある分、普段できないことをしちゃいたいわけですが、「お楽しみ」として、 amazon に注文した本が届きました。

「オブジェクト指向入門 第2版 原則・コンセプト」バートランド・メイヤー著

この本の第１版はすでに読んでいて、素晴らしい名著だと思っています。版型が小さいのでそうでもありませんが、電話帳並の厚さだったりします....（全904ページ）。しかもこれで邦訳は前半だけ、というものです。翻訳者の方に頑張って頂いて、後半も早くお願いしたいものですけどね。

 あ、この本「入門」とタイトルについてますが、全然入門書じゃないです。というか、大学の専門の教科書に「入門」とついているような感じかなぁ。数学書とかだと、「入門」って予備知識を必要とするわけではない、というだけの意味だったりするから、そういう感じで「入門」というだけのことです。

内容は本格的に「オブジェクト指向言語」というものを考察する、というものです。Meyer というと、「契約プログラミング」の概念で有名ですが、要するにこの本は Meyer 自身が「自分の理想」を実現するために設計した言語である Eiffel を「作る」というところから、その中での言語仕様をいろいろと検討していく、というような体裁の本だったりするわけです。

Eiffel という言語はあまり馴染みがない言語なのでしょうが、Pascal 構文的な　ＯＯＰ言語です（比較的影響を受けているのは Ada です）。たとえば次のような特徴を持っています。

1. 多重継承ができる。で、クラスメソッドとかないですから、たとえば数学ライブラリだって多重継承で使います（苦笑）。
2. 汎用体（Generics）を持っている（というか、Meyer によると Generics の「総称性」すなわちＯＯＰの本質的な要素、ということです）
3. ガベージコレクタを備えている（Java っぽいです）。
4. で、「契約によるプログラミング（設計）」をサポートするために、言語仕様として表明を本質的な部分で取り込んでいる。ですから、クラス記述の時に、一緒に事前条件とか不変表明とか記述していくわけです。

まあ、この「契約プログラミング」に関する部分が、今となっては一番議論の的になるような部分でしょう。私は結構この考え方が好きだったりします。簡単に言うと「実社会で契約を結ぶときには、『○○してくれたら、××する』というかたちで、『契約』をするわけだから、プログラム・インターフェイスもこの原理で設計すべきである」という考え方です。たとえば「引数が負でなければ、引数の平方根を返すメソッド」という風に、Math.sqrt() を考えていくわけです。ですから、引数が負でないことの「責任」は、コーラー側で保証すべきであり、sqrt() の側では「もし引数が負ならば何をしてもいい（まあ、トンでもない結果は返すわけにはいきませんから、例外を投げる...くらいが適当でしょう）」ということになるわけです。

これはこれですっきりした考え方だと思います。細かい部分ではもっと面白い仕様とかありますよ。たとえば、「オブジェクトのプロパティが変数フィールドであるかメソッドであるか、は実装詳細である」というのも面白いです。ですから、変数名と同名の無引数のメソッドがあれば、外部からは変数名を隠蔽してしまうわけです。JavaBeans で setter/getter を活用したやり方に今慣れているわけですが、「あ、こういう考え方もアリね」というあたり、面白いです。

あるいは、これは「リファクタリング」でも推薦のやり方ですが、Eiffel は Pascal 風言語のため、function と procedure を区別します。これを Meyer は積極的に捉えて、「function は（目に見える）副作用がない」ということを保証すべきだ、とします。つまり、典型例では getter は function であり、setter は procedure だと捉えるのです。今の仕事だと、副作用てんこ盛りな getter があったりして、私はかなり困っている....わけで、ここらへんもう少しこの考え方が普及するとイイなぁ、などと慨嘆しちゃったりすることもあります（苦笑）。

というわけで、ボチボチ読んでいきます。また面白いところなどご報告しましょう。ちなみに、この本の礼賛だと、今まで見た中では、「オブジェクトの広場」がホントに絶賛です。

ちなみに、わたしはこの本をきちんと読んで理解している人、あるいはEiffelで網羅されているソフトウェア概念すべてについて自分なりに考え抜いたことのある人を除いて、そのひとをオブジェクト指向の専門家とは認めないことにしています。

こんな風に言われる本が書いてみたいです....（←身の程知らず？）

そういえば、結構久々に（３年ぶり？）歯医者に行きました。なんばパークスにあるタワーの中の新らし目の歯医者さんなのですが、実はここ、強烈にデジタル化が進んでいてびっくりしたんです。たまにはこういうことも書きましょうか。

診察チェアの前にモニタがぶら下がってます。で、先生とか技術士さんが使う時には、立ったままで硬いマウスパッドの上でマウスを転がして操作しています。まあ、それだけならば、どうということもないのですが、例によってレントゲンを撮るわけですけど、口の中に入れられるフィルム...じゃなくて、尻尾のついたセンサを入れられるわけです。で、すぐに口の中のレントゲン写真を見せてもらえたわけです。

要するに、これデジタルＸ線撮影、というもののようです。ちょいと調べてみると、デジタルカメラと同じようなＣＣＤによるＸ線撮影装置のようです。レントゲンの世界も直接イメージをデジタルで入力する...ということが急速に普及してきているようなのですね。

考えてみれば長らくお世話になった銀塩技術というものは、現像時に銀を溶かし出してイメージを形成します。現像廃液は環境に結構負担のかかる廃棄物になるわけです（銀の回収システムがありますが）し、撮影からイメージに至るまでの処理時間も化学処理のために多少の時間を要します。こういうデメリットがデジタル化によって改善されるわけですし、患者にとっても別なメリットがあります。

それは、デジタルＸ線撮影だと、フィルム撮影と比較して、照射線量が７０％～９０％減少する...ということのようなのですね（これすごい！）。ですから患者から見た時には、Ｘ線被爆量が減り、より安全な診療を受けられるもののようです。

世の中進歩しているわけです....（デバイス技術系はあまり詳しくないのが個人的には残念です）

前回のエントリで扱った話題と少し関連するのですが、優秀なプログラマのコーディング力とは、天才的なアーチストがその本能のままに振舞うことによる作品と同じような創造プロセスを辿るのだ....というご意見が少し気になったのですね。

でまあ、誰もが「大天才！」で異論のないところでしょうが、モーツァルトについて見ていたら、抜群なページがありました。それは白石知雄氏（プロの音楽評論家です）の「モーツァルトの交響曲４０番」というページです。このページは演奏会の曲目解説で書くものの下書きみたいな感じで、書いたもののようですが、実にこれ、私の耳の奥で痒くて痒くてかなわなかったことを、ばっちり書ききっているのですね。

たとえば....

モーツァルトは、音楽に関して、ちょっと「キレた」感じの恐い人だったんだろうという気がしてきます。ロココでも多感様式でもない18世紀末の「前衛音楽」。
考えてみれば、５度関係の転調は、論理的には無限にどこまでも続けられるので、メモリを食いつぶすまで増殖するコンピューター・ウイルスみたいなことができてしまうわけでシューマンやチャイコフスキーの展開部が強迫神経症みたいに機械的転調で暴走するのにも、ちょっと似たようなものを感じます。モーツァルトがハッカー的にやってみせたデモに、ロマン派の人たちは本気で感染してしまったのでしょうか……）、

といったあたり、モーツァルトの音楽が持っている過激さ、みたいなものを白石氏は正確に理解して、伝えようとしてると思います。というか、例の「モーツァルト効果」みたいなオカルト疑似科学なんて、真面目にモーツァルトの音楽と向き合えば、ホント理解不能なくらいに、「聞いていて実に刺激的」なモーツァルトの音楽の姿をこの分析がしっかり明らかにしています。

ここで「ハッカー」という言葉ですが、よく考えてみれば、大作曲家はみんなどうしようもないハッカーたちだったりするのではないでしょうか？プログラマが論理を細かい部品から組み立てて、大きな構造物を編み上げるのと同様に、作曲家も抽象的な音素材を編み上げて、複雑で互いに関連しあった機能的な全体を構築します。モーツァルトの場合でも特に最後の２つの交響曲は素材が複雑に関連しあい、全体を緊密な総合体として機能しています。

そう考えてみると、たとえばソナタ形式・ロンドのような楽式論的大構造は、ＭＶＣのようなアプリケーション構造レベルのデザインパターンに、カデンツの和声構造はミクロなデザインパターンに...（Decorator とか、５度連鎖の転調に似てません？）、とか対応するのかもしれませんし、優れたプログラマがそういうデザインパターンを発見し、応用するプロセスと、作曲家が新しい和声の連結を発見して作品化するプロセスとも似通っているように感じます。

そういう「優れた（音楽）ハッカー」としてモーツァルトを捉えてみる...というのも面白いと思いますよ！

ウェブを見ているうちに、こんなページを見つけました。

論理的思考の放棄

....まあ、私はこの登氏の能力及び記述内容について論評するのは、面白いことだとは思いません。それよりも、私が「面白い！」となったのは、コメントとレスの多さです。肯定派・否定派（とはいえ興味本位の書き込みは少ないですね）ともに、こういうネタで冷静なコメントが極めて大量についている...ということだったりするのです。

よく考えてみると、プログラマというのは「自分の使う方法論」に極めて敏感な性格を持っています。方法論の流行が周期的にありますし、中には「全然当たってないわけじゃないけど、適用分野はそんなには..」というようなものだってあったりもするわけです。（が、やはり売り込む側はそれを何か「万能の解決策」みたいな雰囲気で売り込むわけです）。これは「銀の弾丸」と呼ばれた時代から、全然変わってない...といえば、それまでです。

やはり、その背景は「自分のプログラミング生産性」に強い関心を持っている...ということなのでしょう。「もっともデキる開発者とダメな開発者の生産性の差は１００倍！」とか言ってアオると、やはりみんな不安になりますよね。そういう「不安な心理」みたいなものが、この「かくも冷静な祭り」の通奏低音のように感じます。

とはいえ、私は少し別な視点なんですけどね、こんなことを考えたりします。要するにこの元記事が単に無視しえないのは、中心的な主張にバリバリに正しい記述がある、ということなんです。私が「正しい！」と思うのはここです。

コンピュータの前に座って、キーボードの上に両手を置けば、後はあまり考える必要はない。自動的に手がキーボードを打ち、プログラムを入力して完成させてくれる。

 純粋なコーディングに関しては、これは絶対に正しいことなのです。事前に書く内容のイメージがつかめていなければ、バグを作るだけのことです。頭の中にイメージがあるのならば、あとはそれをコードのかたちで表現するだけのことであり、「動くものを作る」という視点であれば、脳内イメージを引き写すだけのことなのです。

....しかし、私はそれが重要なことだとは少しも思わないのですね。プログラマが戦わなくてはならない相手とは、次のものごとたちなのです。

• 曖昧な要求と仕様
• 複雑でクセのある開発ツール（ライブラリなども含んで）
• 同僚たちに自分のコードを理解させること
• 後々私のコードをメンテするハメに陥る「未来の同僚」のために、判りやすく・修正しやすく書く

....これら、実際に時間のかかるプログラミング要素の本質というのは、実はすべて「人間に対するコミュニケーション・コスト」です。つづめて言えば「他人の考えを理解し、自分の考え方を他人にわかりやすく説明すること」が、プログラマの最大の仕事のように感じているのです。

要求の根源は人間ですし、既存ライブラリや開発ツールの習得だって、「他人の考え方を理解する」コストです。より明快に、よりメンテしやすいコードを書こう！という気になるのも、「他人に自分の考えを明確に伝えたい！」と感じるが故です。それゆえ、プログラミングの大半の時間とは、そういう「広い意味でのコミュニケーション」の時間に充てられる、というべきなのです。ですから、「コミュニケーションにこそ時間をかけるべき」なのであり、「脳内イメージをコードに反映する」ことなぞ、実は瑣末なことなのではないのでしょうか（けど「もの」としてのコードが出来ないと仕事じゃないですが....笑）

日常的にお世話になっているものですが、JavaScript というのはオブジェクト指向言語の一つである....というのを改めて思い知らされたのは、やはり Ajax の普及でしょう。もともと、JavaScipt 自体の言語仕様はちゃんとしたものだったのです（癖はありますが...）。「ブラウザ専用言語」みたいな格好で使われて、しかもブラウザでのインタプリタ実装がかなりヒドイ状態が長く続いたために、あまり凝ったプログラムを JavaScript で書かない（あと開発環境が貧困）...となっていたのですが、最近ではここらへんが大きく変わったわけです。

たとえば Ajax のフレームワーク的基礎パッケージみたいなかたちで prototype.js が最近よく使われるようになってきています。この prototype.js は「オブジェクト指向言語 JavaScript」を使い倒す！というようなノリで、フルに JavaScript のオブジェクト指向性を活用しているわけです（最初はソースを見るとギョっとしましますが、これ昔からあった機能ばかりです）。

「JavaScript はオブジェクト指向言語である！」ということを確認して、「では JavaScript とデザインパターン」ということを考えてみましょう。そりゃＯＯＰＬですから、GoFのデザパタの大概のものは使えるはずです。勿論アクセス制限はありませんから、Singleton だと裏口を塞げないとか、Facade で公開しないつもりのメソッドが見えちゃうとか、そういう面は仕方がないですし、さすがに Interpreter を JavaScript で実装するのは無意味でしょう（それ自身スクリプト言語ですからメリットないです）。

で、実際に JavaScript で GoF のデザパタをやってみる、というノリのページがありますし、あるいは prototype.js で活用されているデザパタを分析する、というページもあります。あるいは「Ajax のデザパタ」については、これは書籍があってそれを紹介している（未訳ですが）ページがあったりします。

が、「JavaScript 固有のパターンって無いんだろうか？」という疑問も浮かぶわけです。私が考えるに、こういうのはどうでしょう？

名前： Parametric Callback（パラメータ化されたコールバック）

適用：JavaScript から子ページを開く際、子ページのリクエストパラメータに親ページの関数名を渡し、たとえば子ページで「OK」ボタンを押したときなどに、そのパラメータが空でない限り、親ページ所属の関数を名前ペースで起動する。

動機：子ページの部品化を促進する

実装例： （長くなるのでコールバック部のみ）

関連パターン： Observer（GoF）のページ間での応用である。

世の中「役に立つ！」ものばかりではありません。中には「役に立たない」ことがその目的で、「役に立たない」がゆえに、非常に役にたつもの、というものもあります。プログラミングのような、究極に機能主義的な仕事であっても、そういう「無用の用」みたいなことがあるんですね。

考えてみればどんなＣＰＵにだって、何もしない「NOP」インストラクションがあります。これも積極的に何もしないのですが、「後でコードを展開するための穴埋め」だとか、ビジィウェイトするための時間調整のような「役に立つ」使い方があるわけです。

デザパタにもそういう NOP があります。GoF にはないのですが、PLoPワークショップでまとまった「Pattern Languages of Program Design」シリーズ（翻訳）の第３巻で紹介された「Null Object パターン」（報告者 Bobby Woolf）は、通常の仕事をするオブジェクトとまったく同じインターフェイスを備えながら、意味のある仕事は何もしません。役にたつオブジェクトの、「何もしない」バリエーションをわざわざつくっておくのです。何でこんなものが役に立つのか...というとなかなかこれが深いのです。

プログラミングでは、頻繁に null チェックをしますよね。もし引数が null の場合、空文字列を返すけど、null でなければ意味のある文字列を返す...なんて処理を頻繁に書くわけです。実はこれは、この NullObject を使ってそういう null チェック相当処理をオブジェクト自体に任せることができてしまうのです。そういう「null チェックを消す」リファクタリング手法として、例の「リファクタリング」も Null Object を推奨しています。

それ以外にも、たとえば「より意味のあるオブジェクトを作るためのプロトタイプ」としてまずこれを作るとか、JUnit などの自動テストのためにこれを作るとか、かなりいろいろな応用があります。ですから「役にたたない...」というのも実は非常に有用なことだったりするわけですね。

実は私はこの Null Object は愛用パターンの一つだったりします。「GoF 以外で超有用なデザパタ」として紹介しました。皆さんもぜひぜひ研究して使われると思いもかけないような利用法があるのでは...などと思います。

４月ということで何となくせわしい雰囲気もありますが、そういう時にこそ、こういう「無用の用」みたいなことを考えたいですね（苦笑）。

新聞を見てたら、こんな記事が載ってました。

ワード開発　米の富豪　２９億円宇宙の旅に　ソユーズ打ち上げ

で、この「富豪」というのは、チャールズ・シモニーのわけです。例の「ハンガリアン記法」で８０年代中期のＭＳのエース・プログラマだった人ですね。まあ、ハンガリアン記法自体、一時はホントにＭＳ製品のコードサンプルって「ハンガリアン」だったような印象がありますが、最近ではそうでもないですし、コードスタイルについて論じる書籍などでも、ハンガリアン記法の有効性には疑問を呈している方のがよく見かけます。

まあ、それでも若干ハンガリアン？な味があるのは、ＯＯＰ言語で書くとき、インスタンス変数を区別する記法、というのはメリットがあるので、たとえば、

public class Hogehoge {
  private int m_num:
  private List m_jobList;
  public int getNum() { return m_num; }
......

のように、「m_」で始まる、というのは、「m」がメンバの略なので、少しハンガリー風ですね。まあ、そうじゃなくてメンバが _ で始まる、_ で終わる、というような記法で統一されたソースもよく見かけますが、こうなるとＣに由来する public static final な文字定数を全大文字で命名する習慣など決して「ハンガリー風」とは言えない習慣と区別がしにくいです（ちなみにＣでは _ で始まるシンボルはライブラリ内部使用のものなので、アプリで使ってはならないシンボルでした）。

私は....というと、あまりきっちり形式的な命名法で通す..というガラではないですね（苦笑）。強いて言えば、インスタンス変数は長いＯＯＰっぽい名前（昔よく冗談のネタになっていた変数名というと ifRightButtonPressed でしたけど、最近のソースはこれがもう冗談！ではないくらいに長い変数名が当たり前化していますね...）、スタック上の変数はＣ言語っぽい簡略化された名前、という風な感じでしょうか。一時変数に長い名前を付けるのって、あまり意味がないように思いますからね。

要するに説明的なフルスペルのシンボル名を使うべきなのは、略した名前を使うと、略の仕方に揺らぎがあるので、スペルした時に間違えるのを防ぐ...という意味があるように感じています。一時変数だとどうせスコープは今見ている部分だけです。どう略したか、は見れば一目瞭然です。あまり長い変数名を使ってプログラムの構造がわかりにくくなる...のは私はキライです。i, j ならば FORTRAN の昔からループカウンタです。わざわざ myListIndex とかループカウンタに付けるのは屋上に屋を架す、というものだと思います。

また、こういう風にも思います。プログラムの層が下の方になってくると、「すること」単位で機能をまとめ出します。その対象が何であるか、よりも「どういう操作をするのか」の方にポイントが移ってくるわけですよね。そうなってくると、そのオブジェクトが「何であるか」は「場合によって違う...」けど、共通に可能な動作の中での「振舞い方」に共通のものがあって同じメソッドで扱われている、ということも多くあります。たとえばデザパタを使ってうまく抽象化したメソッドでは、「それが何か」は多相の効果もあって「一定でない...」こともあるけど、デザパタの上での特定の「役割」は実に明快、というような書き方になるケースも多いわけです。そうしてみると、これは「何か」よりも「どう振舞うか？」で命名をすべきです。でしたら、あまり長い名前であるよりも、「よく知られた名前」の方がいいに決まっています。

ですから、ＯＯＰの時代になって、さすがにもうハンガリアン記法の出番はない..というように思います。それこそジェネリクスで「型」の一定でない変数をどう命名するのでしょうか（苦笑）。それよりもデザパタで一般に使われる変数名に慣れた方が良いように感じています。

「飛んだプログラマ」で有名な人と言えば、そりゃなんて言ってもゲイリー・キルドールでしょうね。飛びすぎてビジネスチャンスを逃し、これがＭＳの台頭のきっかけになった...というのは有名な伝説です。

前回の「リファクタリング」の続き...というか、今の仕事のソースの問題とも絡んで、ちょっと独立した項目で、神学論争でもしましょうか。

それは「関数（メソッド）の出口（return文）は１つであるべき」か、という問題です。仕事のコードだと、結構こういうコードを見かけます。

public int somMethod( MyObj obj1, MyObj obj2 ) {
  int ret = -1;
  if( obj1 != null ) {
    int id1 = obj1.getId();
    if( id1 > 0 ) { // if文★
      if( obj2 != null ) {
        int id2 = obj2.getId();
        if( id1 == id2 ) {
          /* でやっとしたい処理が始まる... */
        }
      }
    } // endif★( id1 > 0 )
  }
  return ret;
}

たとえばこの if 文★に対して、else 文を追加する変更をするとしましょう。そうすると、処理が長くてエディタから前半がはみでるような状況だと、「あれ、どこに else を追加すれば...」となるのは、はっきり「悪い」ことです。

このようなコードが書かれる原因となったのはいわゆる「構造化プログラミング」の原理に対する誤解が定着したもの...のように思われます。「プログラムはきっちり構造化されなくてはならない」を金科玉条とするあまり、「入り口１つ、出口１つ」というように、これを拡大解釈したのでは...などと感じるわけです。

勿論このコードはこうで構いません。

public int someMethod( MyObj obj1, MyObj obj2 ) {
  if( obj1 == null )   return -1;
  if( obj1.getId() <= 0 )  return -1;
  // endif( id > 0 )
  if( obj2 == null )   return -1;
  if( obj2.getId() <= 0 )  return -1;
  if( obj1.getId() == obj2.getId() ) {
    /* したい処理 */
  }
  return ret;
}

この書き方の場合、関数の冒頭に引数をチェックする return 含みの処理が並列的に並ぶことになります。これはこれで充分判りやすいコーディングだと思いますし、「リファクタリング」でもこれをベックのデザパタ本から借りた言葉で、「ガード節」と呼んで薦めています。

もう少し検討しましょう。この「ガード節」の役割とは、「誤った引数が渡された時に、メインの処理まで処理が渡らないようにする」という「ガード」の役割を果たすものです。勿論、「ＡかＢか」を判定して返すようなタイプの条件とは、全然違うわけで、「正しくこの関数（メソッド）を使う場合、絶対に true にならないタイプの条件」のわけです。そうしてみれば、ガード節というのは、いわゆる「事前条件」なのです。

ですから、この「ガード節」の処理は、本質的には「表明」で処理されるべきものであり、もしプロジェクトに「契約による設計」が導入されるならば、この部分を（どちらか言えば機械的に）表明に書き換えるべき部分だ、ということになります。そういう風に、関数（メソッド）仕様をさらに分節化して捉えるならば、そういう構造を if 文の連鎖は覆い隠してしまうのです！

さらに考えましょう。私がプログラムを学んだ頃..というと、「プログラムは『前処理』『メインループ』『後処理』に分けて理解したほうがいい」などと言われていた時代です。実は私は今もこの概念は通用するものと感じています。もし、Java ならば、こういう構造はどうでしょう？

public int someMethod( MyObj obj1, MyObj obj2 ) {
  // 前処理の感覚（事前条件チェック）
  assert obj1 != null;
  assert obj1.getId() > 0;
  assert obj2 != null;
  assert obj2.getId() > 0;

  // 主処理
  try {
    int ret = -1;
    if( obj1.getId() != obj2.getId() ) {
      /* したい処理 */
    }
    return ret;
  } finally {
    // 後処理
  }
}

finally 節は catch 節がなくても問題なく書けます。しかも finally 節のセマンティクスはそのまま「後処理」なのではないのでしょうか？

ですから、ここでは「目に見える」出口がやはりただ１つになるわけです。return 文は正確な意味での出口ではこの場合ないわけですし、引数チェックは本来表明と統合されるべきです（勿論今は統合されていないので、表明＝引数チェックとするのは危険なコードです）。

毎日仕事していると、なかなか技術書に腰を入れて読む時間を確保しにくいですが、それでももともと技術書大好き人間ですから、多少は本の紹介もいいでしょう。

で、まずはトップバッターは、「リファクタリング」です。この本は「読まなきゃ...」でリストアップはずっとしていたのですが、厚さに比して値段が高い...というケチな理由で後回しになっていた（苦笑）ものです。まあ、「今の古典」の一つであることには異論はないでしょう。

これを「買う！」という気になったのは、今の仕事がどうやらメンテナンス・モードに入りそう...という予定があったりするわけです。年単位で「新ヴァージョン」というタイプの仕事なんですが、来年度版は「あまり新機能を追加せずに、既存コードをブラッシュアップする」というスケジュールになりそうなんですね。というわけで、いい機会なので予習。

要するに、デザパタ＋テスト文化＋リファクタリング、というのが今のＯＯＰの思想レベルでの一番面白いあたり...というのを確認したような感じの本です。GoF のガンマと、XP のベックが仲良し..というのは有名ですが、この本の著者のファウラーも同じ仲間で、ベックが書いている章もあるし、序文はガンマです。ここらへんは結構読んで、デザパタは深めてますから、どちらか言えばリファクタリングの詳細テクニック部分は「わかってるよ...」という感じが私なんかはありますし、逆に「デザパタ入門」としてこの本を使うとなると、やはり少し視点が制限されるかなぁ...という、そういう点で少し食い足りない部分はあったりします。

勿論この本が主張していることは本質的に正しいし、書かれた時点を考えれば画期的です。また翻訳も練れていて、読みやすい...のですが、逆に言うと、もう少しヒッカカリがあった方が私なんかは面白く感じたのではないでしょうか。それでもＸＰのプラクティスにあるような、ややヤンチャ坊主風の「逆説的な正論」をこの本でもブッてまして、そういうのは読んでてちょい元気になりますね。たとえば、

・リファクタリングでより速くプログラミングできる

これはリファクタリングに「難色...」なマネージャを説得する殺し文句に使えそうな議論です。プログラマにとって理解しやすいコードは、修正や機能追加も楽です。

・リファクタリングをすると、一時的に遅くなるかもしれないが、パフォーマンス・チューニングをしやすいコードになる。

これはデザパタを使うときのトレードオフと似た色彩があります。「柔軟性か効率か」というアレですね。一時的に効率を棚上げしても、それに勝るメリットが得られる（とイイんですけどね...）。

まあ、それよりもこの本はベックの言った名セリフを紹介してます。個人的にはベック・ガンマを中心とした Smalltalk コミュニティをルーツとするデザパタ＆ＸＰコミュニティの暖かな雰囲気が若干萌え...というところでしょうか？

「僕は、偉大なプログラマじゃない。偉大な習慣を身につけたプログラマなんだ」

プログラマはこうありたいものです。

（そういえば、私が崇拝する B. Meyer の「オブジェクト指向入門」の第２版の翻訳の最初の１巻が今年１月に出たようです。これはすさまじく「熱い」技術書です。そのうちもっとしっかり紹介します）