この本の感想を一言で要約すると「爽快」というものでした。
まず、この厚すぎないボリュームも素晴らしい。一気に読み切ることができました。「え? これでもう終わり?」と思うぐらいで終わるのが、最も読後感を良くする終わり方ですね。
それにも増して、中身も良い。まさに「爽快」です。もっとも、私にとって爽快なのであって、他の人にとっても爽快かどうか分かりません。むしろ、不快になる人もいるはずです。いるはずですが、あまりそういう声が上がらないことの方が不思議?
それはさておき、なぜ爽快なのか。
それは、2つに分けられると思います。
読んでいて気持ちの良いことが書かれているという要素が1つ。
不快なことが書かれていない要素がもう1つです。
先に不快なことについて書いておきましょう。嫌なことを先に片づけてしまいましょう。
オブジェクト指向について書かれた本を読んでいると、かなりの確率で不快な文章に出会います。それを一言で言い表すと、筋が通らず、自分がプログラムを書いている目の前にある現実と食い違っているようなことを記述している文章、と言えます。
それにはいろいろな文章が当てはまりますが、1つだけ例を挙げると。たとえば、現実世界のものは全てオブジェクトとしてモデリングでき、それをそのままプログラム言語で記述して実現でき、それが上手く機能する、というような無条件の確信というような感じの文章がそれにあたります。モノではない情報を、モノになぞらえる方法は1つのやり方としては良いと思いますが、それが万能であるということや、必ず上手く行くという考えは筋が通らないと思います。世の中には、オブジェクト指向以外のプログラミングのパラダイムはいくらでもあるし、それらが全てオブジェクト指向に劣っている、と言うわけでもないのです。
しかし、この本ではそういう感じの、嫌な臭いを感じませんでした。確かに、この本で扱われているプログラミングは、オブジェクト指向プログラミングではあるのですが、よく見かけるオブジェクト指向とはどこか違うのです。
その理由は、読み進むうちに何となく分かりました。
本文の中に、正確な表現は忘れましたが、メッセージを送信する、というような表現があって、少し首をひねりました。変数を代入したりするだけなのに、それをメッセージを送信すると表現しているようなのです。しかし、ちょっと考えてから分かりました。本当に分かったかどうかは分かりませんが、何となく解釈が1つ出てきました。著者のベックさんは、Smalltalk使いです。そして、Smalltalkのオブジェクト指向は、C++やJavaのオブジェクト指向とは、ちょっと違うものであるはずです。残念ながらSmalltalkは全く触れたことがないので、確実なことは言えませんが、ともかく違ったと思います。おそらく、ベックさんにとってのオブジェクト指向とは、複数のオブジェクトがメッセージを交換しあって動作するモデルを意味するのでしょう。それは、thisポインター付きの関数に過ぎないメソッドや、ただの変数に過ぎないpublicなメンバー変数を記述できてしまうC++やJavaやC#のプログラミングモデルとは異質なものです。ここでは仮に前者を「プロトタイプ・オブジェクト指向」、後者を「量産型・オブジェクト指向」と呼んでみましょう。「プロトタイプ・オブジェクト指向」では、オブジェクトという単位が通信するモデルそのものに、オブジェクト指向の本質があります。しかし、通信という概念が希薄な「量産型・オブジェクト指向」では、そのようなモデルよりも、オブジェクト指向的なモデリングの方に重点が置かれているように思えます。そのような観点から、「クラスの責務」や「自然な役割分担」という言葉が重い意味を持ちます。しかし、それは「量産型・オブジェクト指向」での話であって、「プロトタイプ・オブジェクト指向」では状況が違います。そして、「プロトタイプ・オブジェクト指向」の人であるベックさんにとって、「クラスの責務」や「自然な役割分担」を考えるよりも、重複を除去することの方が重要である、ということなのかもしれません。つまり、オブジェクトはメッセージを交換する主体となることが第1義であって、メッセージを交換する主体としての適切さを維持することが重要というわけです。それに対して、オブジェクトがどんな役割に擬せられるかは、あまり重要ではないということです。
という解釈が正しいかどうかは分かりませんが、ここは感想文を書くカテゴリなので、読んだ感想をそのまま書いておきましょう。
(ちなみに、メッセージを交換する主体、という機能は、あるOSのある重要な機能で嫌になるほど使った経験がありますが、そのうちに時間があれば書きましょう。それまでは、具体的に何を意味するかは秘密です。分かる人には分かると思いますが)
さて、ここで話は変わります。
読んでいて気持ちの良かったことについて書きます。
Part1は小さな例をいじりながらテスト駆動開発(TDD)を行う実例を示したパートです。TDDそのものは、テストファーストの延長線上にあるもので、テスト駆動で開発を行うことのメリットを今更感想文に書いても、もはや意味がないことですね。
それよりも、けっこう面白いと思ったのは、ドルとフランを扱うクラスを開発していく際に、途中でポリモーフィズムを使った抽象マネー・クラスと、ドル・クラス、フラン・クラスが生まれたにもかかわらず、ガンガン、コードから重複を取り除いていって、最終的にドル・クラスとフラン・クラスが消滅してしまったこと。クラスが持つ責務ということも、自然な役割分担ということも言いません。こういうのを見ていると、ケント・ベックという人とは、どこか波長の合う部分があるような気がします。似ているとか、同じ主張をしているとは言いません。明らかに違う部分はありますが、それでも、どこかに似た部分があるような印象を受けます。
Part2は、xUnitをTDDで開発するというものです。いきなり実用的な大物が来る、というのも面白いのですが、それよりも面白いのが、Pythonが使われていることです。Part1はJavaを使って解説が進んでいたわけですが、いきなりここからJavaではなく、Pythonでやっています。合理的であると同時に、この大胆不敵な奇抜さは好感ですね。
Part3は、テスト駆動開発のためのパターンをいろいろ書いてあります。特に好きなのは、シングルトンについて書かれた部分です。
「グローバル変数のない言語でグローバル変数をどのように提供するのか。→そのようなことを考えてはいけない。そのようなことを考える時間を設計に費やせば、プログラムがよりよくなる。」
これで終わりです。このストレートで簡潔な言い切り。痛快で爽快ですね。こういうのが読めるから、この本は気持ちがよいです。
もちろん、自分のプログラムでシングルトンになっている部分が、それで良いかどうか考えてしまいました。必要だからそこにシングルトン・オブジェクトがあるのだ、と最初は思いましたが、すぐに気付いて考えを変えました。必要だというのは、単なる思い込みかも知れませんから、再考する価値はあります。
というわけで、実際に、自分のプログラミングスタイルを、この本を参考に少し変えてみました。小さな単位で、レッド・グリーン・リファクタリングを回してみると、これもとても気持ちが良いものだと思いました。
この本は、数年に一度の名著だというのが、感想の結論です。
