@ITのメールマガジン「＠IT先週の人気記事 - 2004/8/23 ネット管理者のためのWindows XP SP2レビュー（前）」にて、拙著継承とは隠された条件判断である」が＠IT 総合週間ランキングで第10位になっていました。
ある意味、この話題は極めてプログラム言語ミーハー的な内容と言えます。オブジェクト指向信仰的に考えても異端的でしょう。それを考えると、ぎりぎりベスト10の10位であっても、かなりの大健闘と言えますね。
以下は全くの余談なので意味が分からない読者が99.99%だと思いますが §
この記事に関してあとから思い付いたことがあります。
継承、より正確にはポリモーフィズム、もっと直接的には仮想メソッドというものは、実装の構造から言うと、間接サブルーチンコールに相当する機能によって実現できます。たしかC++あたりは、そのような理解で良いはずです。VB.NETの場合は、実装がどうなっているのか分からないので、それで良いかどうか分かりませんが。
さて、そのように考えて、条件判断を間接サブルーチンコールに置き換えることができる、という話に相当するな、と思った瞬間に気付きました。
そのテクニックは、1980年代の前半の時点で、既に多用していたじゃないかと。
処理に複雑な条件判定が付く場合、先に条件を判定して、処理を行うサブルーチンのアドレスを特定のメモリに書き込んでおきます。あとは、それを間接サブルーチンコールするだけ。メモリの節約と、処理速度の向上をもたらし、しかもソースをすっきりさせる定番のテクニックでした。
更に、各機能ごとのコール先アドレスをテーブルにしたものを用意して、これを条件に応じて切り替えるような構造にしたとします。これも、当時、けして珍しい構造ではありませんでした。しかし、これこそは一種のシンプルなポリモーフィズムに他なりません。新しいテーブルを追加すれば、元プログラムを修正することなく機能を拡張できますから、拡張性という点でもポリモーフィズム相当と言えます。
そう考えると、実はアセンブラからポリモーフィズムに直接続く、間接呼び出しテクニックの隠されたコンテキストが存在することが分かります。けして、オブジェクト指向プログラミングは、不連続に進化して生まれた隔絶的な存在ではない、と言うことですね。しかし、あくまで最初にモデルありきという立場に立てば、このような連続的な世界観はプログラムの構造に対する認識のアップデートを阻む悪い世界観ということになるかもしれません。つまり、アセンブラみたいなものという理解をしていては、いつまでも経っても本当の意味でオブジェクト指向らしいプログラムを書くようにならないかもしれない、と言うことです。しかし、この世界にたった1つの唯一の正解など存在しない、という原則が正しいとすれば、ある機能を理解するためのアプローチが複数あるのは健全で望ましいことだと思います。
更に良く分からない感想が続く (笑 §
実は、間接呼び出しテーブルのテクニックは、一部のBASIC言語処理系で実践できることに気付きました。これを書いている途中で。
一部のBASIC言語処理系では、計算型goto文というものが使えます。これは、gotoやgosubの飛び先の行番号を、計算式で指定できるものです。ちなみに、マイクロソフトのBASICなどでは、計算型goto文は使用できず、そのかわりにon … goto文などがあります。計算型goto文が使えるのは、Palo Alto Tiny Basicなどの小さな処理系が多いように思います。
さて、話を戻すと。
計算式で指定できるということは、変数を書くことも当然OKです。
変数に、呼び出し先の行番号をあらかじめ入れておいて、"gosub 変数名"とすれば、条件判断を書かずに条件によって処理を変えることができます。更に、個々の機能に対応するサブルーチンの行番号を含む配列を用意しておき、これを条件によって取り替えるようにすると、一種の原始的なポリモーフィズムが実現できます。
と言うわけで、トラブルの元としてイマイチ嬉しくない機能だった計算型goto文に、こんなあっと驚く使い方があったとはBASICもやるじゃん、という無責任な結論で話は終わりにしましょう。なぜ無責任かって? そりゃもちろん、こんなテクニックを使うとソースが強い意味を持つ行番号の塊になって、読みにくく、メンテしにくくなってしまうからです。現在のオブジェクト指向プログラム言語は、少なくとも遥かに読みやすいソースを書けます。その点で、明らかなプログラム言語の進化が見られる、という考え方はあり得るでしょう。
