オブジェクト指向入門をもう一度

プログラミングが好きでTDDが好きで昔話に興味があるあなたに「オブジェクト指向入門」を勧めます。

いまさら「オブジェクト指向」に「入門」なんて、と思うかもしれません。ちょっと控えめなタイトルのこの本は、私のプログラミングスタイルにとても大きな影響を与えました。
私はこの本から著者メイヤーの説く多くの概念を学んだだけでなく、言語デザインからその意図や主張を汲み取ることの楽しさも教わりました。私にとってはプログラミングの指針を両面から得られた、プログラミングの入門書でした。それから、やり過ぎに注意、という教訓も得たような気がします。

メイヤーはEiffelという言語を用い、「モジュール」を出発点として様々な議論を展開します。インターフェイスの重要さ、契約／表明を使ったデザイン、開かれてかつ閉じている開放／閉鎖原則を満たす型システムなどなど、「正しいソフトウェア」を構築するためのさまざまな概念を説明しています。今ではどの概念も広く知られるようになったと思います。たとえば、DbCーDesign by Contractという言葉をご存知の方は多いのではないでしょうか。契約と表明はこの本の主要なテーマとなっています。

この本で扱う表明はいくつかありますが、私が関心を持ったのは事前条件と事後条件です。あるメソッドを利用するにあたってアプリケーションが保証しなくてはならない条件が事前条件、呼び出された結果にメソッドが保証する条件が事後条件です。この他にもクラスがいつでも満たさなくてはならない不変条件などがあります。Eiffelがちょっと特別なのは、これらの表明を言語仕様として持っている点です。この構文を使うとソフトウェア自身の検査のためのコードをインターフェイスに記述することができます。DbCは契約という概念でインターフェイスを設計しますが、Eiffelは構文でDbCを支援してくれているわけです。付録に基本的な集合構造のインターフェイスの抜粋が出ていますが、ここでも主役は表明です。そのインターフェイスはクドいくらいに説明的で、同じように自分が書けるんだろうかと心配になります。この構文を無視してプログラミングできるでしょうけど、用意されていれば使ってしまうものです。メソッドを書くときは実装の前に事前条件、事後条件について考えることでしょう。

ソフトウェアの仕様をコードで表すと言えば、TDDなどにおけるテストケースを連想させます。それは実行可能な表明の一種に見えます。TDDのテストケースの場合、そこには具体的なサンプルデータが含まれていて、仕様の表明というよりもむしろ最初で最小のアプリケーションの記述に近く、あるサブルーチンに対する検査というよりも一連のサブルーチンの利用方法について確かめるものですが。

表明のように、この本のなかで紹介される概念の多くはEiffelに構文として組み込まれています。Eiffelはまるでメイヤーのアイデアを自然に説明するために生まれてきたように思えてきます。やり過ぎ感のある言語仕様もそう考えると納得がいきますし、もしかすると本当にそうなのかもしれません。道具は思考を規定するときいたことがあります。Eiffelでナチュラルにコードを書くことはメイヤーの主張する「正しいソフトウェア」に近づく一歩なのかもしれません。
きっとメイヤーだけでなく多くの言語設計者は、自分の伝えたいことをプログラミング言語の設計に載せて伝えているのでしょう。とするなら、自分が使っている言語からも何らかの意図を汲み取るのは素敵なことではないでしょうか。いつのころからか、私は言語やライブラリの設計者の意図に沿うような、言語と対立しない、自然なコードを書きたいと思うようになりました。

なお私のCのコードの抽象データ型がCreate()とForget()を持つのはEiffelへのオマージュです。これはいろんな言語でEiffelのアイデアを試そうとした頃の名残りです。RubyのensureやrescueもEiffelから予約語だけ受け継いだと聞きました。とても堅い言語がとても柔らかい言語に跡を残してるって面白いでしょ。

私の机の上には初版の初刷（1990年）が飾ってあります。この初刷は著者名が間違っていて、ちょっとしたコレクターズアイテムです。私はときどきその広い背表紙を眺めてにやにやしています。20年経った今なら、上下分冊の大作となった第二版を手に入れることができます。