今月も月末に向かって地味に忙しくなって更新が遅れてしまいました・・・。

　前回と前々回に分けてダブルディスパッチについて説明しました。前回の繰り返しになりますが、この考えをさらに進めると複数のオブジェクトに対してポリモーフィズムを効かせればどうなるか？という話になります。一般化ですね。もっとも残念ながら、３つ以上のオブジェクトに対してポリモーフィズムを効かせる具体例が思いつきません。まぁ、『３者面談をやった時の先生と生徒と保護者の性格別の対応策』というのも考えられなくはないですが、今まで３つ以上のオブジェクトに対してポリモーフィズムを働かせた実戦経験はありません。ただ、この一般化－マルチディスパッチとかマルチメソッド－というアイデアを頭の隅に置いておくといつか使える日が来るかもしれません。

ｎ体のオブジェクトに対してポリモーフィズムを働かせる。

と考えた場合、『n=0の時はどうなるか？』という考えが湧いてくるでしょう。そうです。n=0の時はメソッドに関係するオブジェクトが無いと考えられます。従来の関数がそれにあたります。
C++は自然に関数が定義できるのですが、JavaやC#は悪名高いpublic staticメソッドを使って関数を定義します。

以上が前回の復習になりますが、さて『関数が必要となる場合』の具体例をあげましょう。こちらもC++のライブラリからになりますが、一般的に以下のようなアルゴリズムの実装はオブジェクトと関係ないということで関数（正確にはテンプレート関数）で実装されています。

・合計値を求める
・ソートを行う
・検索を行う。

JavaやC#のみ知っている方はこの事実に驚かれるかもしれません。が、アルゴリズム＋データ構造＝プログラムという古典を知っている方なら逆に納得してもらえるかもしれません。つまり、データ構造に対して独立した手続き－アルゴリズムを考えた場合、関数での実装が上手くいくということになります。
それでもまだピンとこない人がいるかもしれません。そういう方はジェネリックプログラミングについて調べてみるのも良いかもしれません。この連載でジェネリックプログラムを扱うのは話が発散するので今は避けますがJavaにしてもC#にしてもジェネリックプログラミングをサポートしていますが、オブジェクト指向プログラミングとは必ずしも相容れるものではありません。

ということで関数（手続き）は、アルゴリズムの実装と相性がいいという話をしました。他には、実はかのstaticおじさんと揶揄されているみながわさんが指摘した、通常の手続きにも関数が使えるという話をします。
さて、みなさんがあるアプリケーションの実装時に、あるURLで指定されたHTMLファイルを取得する必要があった場合、以下の2つのライブラリのうちどれが便利に使えるでしょうか？

関数 gethtml を使う。
URLクラス、URLConnectionクラス、InputStreamクラス、BufferedReaderクラスを使う。

もし、各種クラスを使う方が便利と思うなら、あなたを『オブジェクト指向おじさん』に認定しましょう。
gethtml関数の方が良いのは自明でしょう。もし疑問があるのならコメント欄に質問してください。

さて、次回は変数の共有との関係で関数とメソッドを比べてみます。

　連載も5回目になりましたが、まだモチベーションが維持できています。前回はダブルディスパッチの説明と共にメソッドと関数について本質的な違いはないという説明をしましたが、もう少し突っ込んで話をします。
もともと
object.method();
という表記は、methodがobjectのクラスに属しているという意味合いが強いかと思います。言葉を変えるとクラスとはデータと、そのデータを扱うコードが合わさったものという発想です。これはこれで一つの考え方で構いませんが、問題は全てをメソッドにするのも間違いだということです。その一例がダブルディスパッチということになります。以下のように加算演算子+を考えた場合、

object1 + object2

+演算子は
　1.object1に所属するのか？
　2.object2に所属するのか？
　3.両方か？
　4.どちらでもないか？等々
1-4の内どう考えるのが自然なのか？という問題に突き当たります。Javaは演算子のオーバーロードを禁止することによりこの問題から背を向けました。つまりこの問題を避けているとも言えます。ちなみにこのような仕様を見たときにJavaは補助輪が付いた自転車のような印象を受けました。C++は『どちらにも属さない』書き方ができます。正確にいうと『object1に属する』の書き方も場合によってはできますが、例えば、

10 + object

のような場合は、『どちらにも属さない』書き方でしか書けません。つまり関数を使ってオーバーロード演算子の定義を行います。C#はある意味『どちらにも属さない書き方』で書きます。つまり、多くのオブジェクト厨が忌嫌うpublic staticメソッドでオーバーロード演算子の定義を行います。

ダブルディスパッチの話を終える前にマルチディスパッチ（マルチメソッド）の話を軽くします。前回、2つのオブジェクトに対してポリモーフィズムを働かせる仕組みをダブルディスパッチと説明しましたが3つ以上のオブジェクトに対してポリモーフィズムを働かせる考え方もちろんあり、マルチディスパッチまたはマルチメソッドと言います。マルチメソッドをいつ使うのか？と言われたらそれはそれで考え込んでしまうのですが、それでも、メソッドが何処かのクラスに属するという考え方に固執するとこのようなパラダイムを受け入れることは難しいでしょう

さて、このようなある種の一般化を行った後は、今度は全くクラスに属さない手続き=関数という存在も自然に受け入れることができるかと思います。つまり、

y = sin(x);

のような式において、文字通りの関数、sinはどのクラスにも属さないと考えた方がよいでしょう。「Mathクラスに入れたらいいだろう」と反論を受けそうですが、実際にsin関数はJava厨が忌嫌うpublic staticで定義されており、C++でも関数として定義されています。先の演算子の例でも出てきましたが、public staticメソッドとは手続型言語での関数定義に相当するものになります。ちなみにかのεπιστημηさんは私との議論で、

Java/C#はどのクラスにも属さないメソッドが作れないため、
当たり障りのないクラス(たとえばMathあるいはModuleC)をでっちあげてそいつに押し込まざるを得ない。
「いかなるクラスにも属さない」という”思い”を表現できません。
僕にはそこが(C++と比べて)不自由に感じます。

というふうに本質的に関数であるものを仮のクラス（Math）に入れることには難色を示されています、これについては私も同感です。

さて、『そんなに関数が重要ならsinとかではなくもっと幅広く使える例を出せ！』と言われそうです。その答えは来週に行うということで。

　なんやかんやでかろうじて連載も4回目になりまして、モチベーションも維持できてよかったです。語学留学もあと一カ月で、最近、仲良くなった大学生にC++を教えています。といっても最初はポインタを教えていたのですが次にリファレンスを教えることになって、思わず、「混乱の元だからリファレンスは最初は無理して覚えなくてよくてポインタを先に覚えましょう。」と言ってしまった。もっとも「リファレンスの方が簡単だから軽く覚えてガッツリポインタを勉強しよう。」とも言ったが、この連載のターゲットは『オブジェクト指向しか知らない世代』としていますが、JavaやC#しか知らない方たちはポインタの概念が理解できているか怪しい限りです。興味深いのは、私の半径3メートルの範囲、クパチーノ近辺ではC++をマスターすることがステータスになっているようです。

　という訳（？）で今回はメソッドと関数について話します。なぜか知らぬがネットの界隈ではどうも、

メソッド＞＞＞どうしようもない壁＞＞＞関数

という図式が成り立っているようです。でこのどうしようもない壁なんて無いというのが今回のテーマです。もっとも1回で説明するのは難しいので何回かに分けて説明します（しかも飛び飛びになるかも）。

先ず、最初に以下の2つの表現

object.function();

function(object);

ですが、C++でみると生成される機械語コードは同じになります。例外はfunctionが仮想関数（ややこしいので以下、オーバーライドメソッドと呼びます）の場合になります。オーバーライドメソッドを除いて、C++でみると上記の2つのコードは同じということになります。『カプセル化があるだろ』という突っ込みがあるかもしれませんが、それは他のキーワード（friend）を使うことによって同等にできます。
もし、あなたには『どうしようもない壁』が見えるというのならどうぞ具体例とともにコメントをください。

ということで、ADPでは上記の2つのコードは同じように解釈されます。というか上のコードは下のコードとして解釈されます。『同じなら一つの書き方で良いだろ！』とお叱りを受けそうですが、表記上の重要な違いがあります。つまりobject.function()の記述はメソッドチェーンを実現できます。

object.function1().function2().function3();

もしこれを関数の形式で書くと

function3(function2(function1(object)));

となりますが、どちらが良いかは一目瞭然だと思います。ただ、これはあくまでも表記上の話でもしこれがどうしようもない壁というのならオブジェクト指向というのは表記上の問題ということで話が付きますし、そもそもメソッドチェーンの見た目はもはやメッセージパラダイムとは異なるでしょう。

さてfunctionがオーバーライドメソッドの場合の話ですが、簡単にオーバーライドメソッドについて話ますと、呼び出されるメソッドが実行時に決定される点です。C言語の関数は呼び出される実体がコンパイル時に決まりますが、オーバーライドメソッドの場合は実行時にオブジェクトの型によって呼び出される実体が決まります。

object.add(1);

とあった場合、objectがInteger型ならIntegerクラスのaddが呼び出され、objectがFloat型ならFloatクラスのaddが呼び出されるということになります。これはポリモーフィズムと呼ばれるもので、オブジェクト指向病にかかっている人たちはまさにポリモーフィズムが手続き型言語との差別化を図っていると信じています。ポリモーフィズムについては連載の後の方で詳しく説明しますが、関数ポインタを使うとこによりCやアセンブリ言語でも同様の機能を実現できます。こう言うと『ならアセンブリ言語で全部書けや！』と意味不明な切り返しをされるのですが、それに答ますとLinuxの記述では主にCが使われているというのは有名な話ですが、でデバイスドライバの実装等ポリモーフィズムと同様のことが行われています。つまりCでもある程度はオブジェクト指向を実用レベルでシミュレートできるということです。ちなみにADPはC++で記述しておりポリモーフィズムもバリバリ使っていますがパフォーマンス上の理由からCでリライトしようかと思案中です。

さて、話が横道にそれましたので元に戻しますとaddの例ですが、何か変なことに気付かないでしょうか？例えば以下の例はどうでしょうか？

object1.add(object2); // ・・・・・(A)

このaddメソッドですが、object1に対してはポリモーフィズムが効きますがobject2に対してはどうでしょうか？JavaやC++ではobject2にはポリモーフィズムは働きません。まぁ関数の例でもそうでしたが引数にはポリモーフィズムは働かないと考えてもしようがない面もありますが、もし引数にポリモーフィズムが働かないのが当然だというのなら(A)は以下の例と動作が異なることになります。

object2.add(object1); // ・・・・・(B)

加算(add)というのは通常交換法則が成り立ちますのでもし(A)と(B)の動作が異なるということならその実装は不完全としか言いようがないですね。ので通常addがポリモーフィズムであるならそれはobject1,object2双方に対してポリモーフィズムでなければならないことになります。2つのオブジェクトに対してポリモーフィズムを働かせることをダブルディスパッチと呼びます。私はダブルディスパッチについて16年程前に『More Effective C++』で知ったのですが、以前、といっても2，3年程前にJavaが得意で自称オブジェクト指向をマスターしている彼が『オブジェクト指向をマスターしている人は日本にはほとんどいない。俺を除いて』と言っていたので『ダブルディスパッチって知っている？』と聞いたら『なにそれ？』と返されたことがある。ということで知ったかのJava厨の検出にはダブルディスパッチは今のところ効果的かと思われる。ちなみにC#4.0以降の場合、dynamicキーワードを使うことにより(A)の記述でもobject2に対してもポリモーフィズムを働かせることができるのでC#プログラマにダブルディスパッチの技を繰り出すのは返り討ちにあう可能性があるので注意したい。話を戻してC++やJavaの場合はかの有名なデザインパターンの一つビジターパターンがダブルディスパッチの実装方法の一つとなる。
ダブルディスパッチの使いどころですが、二項演算子でポリモーフィズムを使いたいとき（もっともパフォーマンス上の問題があり二項演算子でポリモーフィズムは使わない場合が多い）や2つの物体の衝突を計算する場合（More Effective C++）があるでしょう。ADPではユニフィケーションの実装にビジターパターンによるダブルディスパッチを使用しています（これがしたいが為にC++を使ったがもっと効率的な記述をしたいからCで組みなおそうかと考えている）。

つまりこういうことになる。

object.method()

と

function(object)

において表現上の違いやプログラミング言語のサポート状況による違いはあるが本質的には両者を同等物とみて構わないということである。つまりどうしようもない壁はないということになる。

長くなったので続きは来週に持ち越します。

先週に続きましてオブジェクト指向再考ということで特にオブジェクト指向に毒された方を対象に現実的な観点でプログラムできるように、プログラマとして社会復帰できるように、ヒントを出したいと思います（もちろん回復するかどうかは本人次第です）。
今週からはメッセージについて話たいと思います。世の中には、

メソッド（メッセージ）>>どうしようもない壁>>関数

と思っている方がいらっしゃるようですが、今後数回に分けて、この『どうしようもない壁』というのはオブジェクト指向病特有の幻覚であるということを示したいと思います。まぁ、厄介なことに患者さんには明確に壁が見えているのでなんとも言えないのですが、もし少しでも『これは幻覚かも？』と思った方はこの連載が助けになるかもしれません。ちなみに『この壁を感じれないやつはプログラマとして終わっている』とお思いの方はお帰り頂いて構いませんし、反論のコメントを書き込んで頂いても構いません。

前回の最後に示しましたが、オブジェクト指向のキーファクターとしてメッセージがあります。この考え方（パラダイム）はそれはそれで素晴らしいものです。分かり切った例をあげますと、マウスの入力（クリック）がメッセージとしてOSに伝わり、イベントハンドラ（コールバック関数）に制御が引き渡されます。当たり前のようですがこの仕組みはメッセージパラダイムを具現化したものになります。もしメッセージを使わなかったら、例えば定期的にマウスの位置を読み込み、クリックされたどうかを確認することになります。考えただけでも厄介ですよね。GUIプログラムがイベント駆動型と言われる所以ですね。

さて、ここでのキーポイントは、『世の中の事象は全てイベント駆動（メッセージ）で記述するのが良いことか？』ということになります。例えば、以下のプログラムを考えましょう。

ユーザがスタートボタンをクリックしたら画面に”Hello”と表示する。

間違いなく、『ユーザがスタートボタンをクリックしたら』、というところはイベント駆動と相性がいいですね。では次の

『画面に”Hello”と表示する。』・・・・・(A)

というのはどうでしょうか？この部分はイベント駆動またはメッセージで記述できるでしょうか？

よくオブジェクト指向の教科書に出てくるのですが、

『画面オブジェクトに、引数に”Hello”を指定して表示依頼のメッセージを送る。』・・・・・(B)

というのを見受けます。最初に指摘しますと(B)は(A)を劣化させたものだと言えます。
ポイントは(A)は手続き指向で書かれて、(B)はオブジェクト指向（メッセージ指向）で書かれています。そして重要な点ですが、この場合、(A)はプログラムの仕様（本当にやりたいこと）を表していて(B)はプログラムそのそのものの説明を行っている点ということになります。つまり、(B)は以下のようなコードの説明を行っているということになります。

label.setText(“Hello”);

ここで画面オブジェクトというのがlabelになり、setTextが表示依頼メッセージで”Hello”が表示対象の引数ということになります。
つまり(B)は上記のコードの説明を行っていることになり、(A)は上記のコードの意図を表しています。
もし上記のコードにコメントを付与する場合、（A)、（B)どちらが良いでしょうか？

label.setText(“Hello”); // 画面に”Hello”と表示する。・・・・・(A)

label.setText(“Hello”); // 画面オブジェクトに、引数に”Hello”を指定して表示依頼のメッセージを送る。・・・・・(B)

(B)の方がよいという考え方の人に質問したいのですが、ラベルオブジェクトに値をセットする方法にはプロパティを使うというものもあります。つまり以下のコードもありえます。

label.Text = “Hello”;

この場合、(A)、(B)どちらのコメントの方が適切でしょうか？

label.Text = “Hello”; // 画面に”Hello”と表示する。・・・・・(A)

label.Text = “Hello”; // 画面オブジェクトに、引数に”Hello”を指定して表示依頼のメッセージを送る。・・・・・(B)

それとも以下のようにコメントするのでしょうか？

label.Text = “Hello”; // ラベルプロパティに”Hello”をセットする。・・・・・(C)

もっとも、(C)のような発想もオブジェクト指向から離れたと言えるでしょう。
さて、ある程度経験のあるエンジニアなら大なり小なりこのようなジレンマを抱えたことがあるかと思います。つまりメソッドの中身を書こうとしたときに『どうもオブジェクト指向していないな・・・』と感じることがあったかもしれません。しかしよく考えてみれば分かりますが、メッセージ指向というのはある種の手続きの上っ面（呼び出し方法）についてパラダイムであり中身をどうするかは別問題ということに気付くかと思います。
ここで重要なことは、

メッセージというのはプログラミングパラダイムの一つであり、メッセージで表現した方がよいもの（例えばイベント）もあれば、そうでないもの（手続き指向のもの）があるということで、プログラマは適宜適切なパラダイムを選択してプログラムを行えばよいです。多くのプログラマは、プログラミングパラダイムについて

オブジェクト指向（メッセージ指向）> 手続き指向

と考えているかもしれませんが、実はそれぞれ適材適所があり適宜使用すればよいということになります。つまりマルチパラダイムですね。さてオブジェクト指向言語しか知らない方は実は手続き指向という発想がないかもしれません。何かをステップバイステップで処理をするという発想が手続き指向になります。特段難しいとは思えないですが、もしピンとこない方がいらっしゃいましたらコメントを下さい。
イベント処理を手続き指向で考えるのは不適切ですし、能動的に画面に何か表示したいと思った時にいちいちメッセージ云々を考えるのも不適切ということになります。そう考えると以下の2つの記述方法のどちらかが適切か理解できるかと思います。

z = 3 * x * y + 4 * x + 6 * y + 2;

z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2);

もう迷う必要はなく上の方が適切だと理解できるかと思います。数式も一つのパラダイム（というか表現方法の一種）だと理解すれば無用なパラドックスに悩まされる必要もなくなります。

次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。

　前回出した記事（オブジェクト指向おじさん？）のあいださんのコメントで最も興味深いものが、オブジェクト指向しかしらないプログラマが増えてきている、というものである。実は私はそれまで『なんでこうオブジェクト指向信者が途絶えないのか？』と疑問に思っていたのだが冷静に考えれば解るとおり『良いも悪いもなくソレしか知らない。』（あいださんのコメント）世代が増えて来ているようだ。幸いにして私の周り半径3メールではそんな奴はいないので私の視野が狭くなっていたらしい。そういう意味では前回の記事をアップして良かったと思う。
また、元々、オブジェクト指向に関する記事を書こうかと思って対象読者を従来の手続き型言語に精通している人としようかと思っていたのだが方針を若干変更してメインターゲットを『オブジェクト指向しか知らない世代』にして、今後増えるであろう、オブジェクト指向症候群に掛かった患者への処方箋を今後数回に分けて書くことにする。
　オブジェクト指向という言葉を聞くとみなさんはどんなイメージをもたれるでしょうか？『オブジェクト指向とは何か？』を素人に説明するとプログラミングパラダイムの事でつまりプログラムを開発する上での一つの考え方や一つの模範ということになる。実はこれ以上でもこれ以下でもないのですが、もしあなたが以下のどれか２つに当てはまるのならオブジェクト指向症候群に掛かっているかもしれないので、この連載は役に立つだろう。

　１．関数という言葉に嫌悪感を感じる。または時代遅れの遺物だと感じる。
　２．よく他のプログラマ・言語に対して『オブジェクト指向ではない』と言っている。
　３．staticを使っている人をみるとプログラマとして終わっていると感じる。
　４．過去にオブジェクト指向を批判した記事を読んだが書いている奴がオブジェクト指向を分かっていないだけだった。
　５．C++が最高、他の言語はダメと思う人。
　６．Javaが最高、他の言語はダメと思う人。
　７．C#が最高、他の言語はダメと思う人。
　８．と言いつつも、自分自身がオブジェクト指向というのが何か実は良く解っていない。

さて、こういうと『お前が解っていないだけだ』と批判を受けそうなので少し私自身について説明します。私は14歳の時からプログラミングを初めて今年で32年目になります。仕事で使った言語は、覚えた順からBasic,Assembly,C,C++,VB,SQL,Java,Perl,PHP,MDX,Ruby,VB.NETです。ちなみにAssemblyは複数のCPUのインストラクションセットを覚えたし、実際に20年前まで仕事で使っていました。メジャーな言語ではC#が抜けているがやったことがないだけです。オブジェクト指向についていうとこれまた20年以上の経験になり、いわゆる手続き型言語からオブジェクト指向言語へコンバートした人になります。批判される前に私のオブジェクト指向の経歴をいうと、十数年前にJavaの記事を書いたこともあるし、ADPというプログラミング言語のプロジェクトを持っているがこれはC++で書かれています。またADPもオブジェクト指向をサポートしてます。その関係で一般のプログラマよりもオブジェクト指向についてよく考えていると自負している。

さて、まず最初の処方箋を言うと、オブジェクト指向は過大評価されている点を挙げましょう。実際は全くそんなことはないのにも関わらず、『オブジェクト指向はプログラマが進む最終地点』と考えている人が多いでしょう。歴史的にみてオブジェクト指向が持てはやされたことがありそれに無意識に乗っかっている人々がいたということもあるが、実はオブジェクト指向自体になにかプログラマを引き付ける魅力があります。ある人はそれを『究極の一手』と表現し、またある人は『彼女（彼氏？）』と言ったり、私自身も『オブジェクト指向はプログラマが進む最終地点』と考えていた時があった。さてここまでで『私がオブジェクト指向を理解していない』と思ったあなたは充分オブジェクト指向病に冒されていますので、何かコメントをしよう考えたのなら少し我慢して以下を読んで頂いて反論を頂きたい。

誰でも知っていることだがオブジェクト指向というのはもともと分類学の技法をプログラミングに取り入れて複雑なプログラムに対応しようというパラダイムの一種で、クラスとか継承とか多態性という言葉は分類学から借りてきたものであるといえる。ここで冷静になって考えてみれば分かることですがそもそも世の中の全ての事柄を分類学でカバーできるでしょうか？世の中の学問を見渡せば分かるとおり分類学では全てはカバーできないことは理解できるでしょう。つまり継承とか多態性というのは一部の領域にのみカバーをすることが保障されているということであり、ここで代表例を挙げると、GUIシステムにはオブジェクト指向がうまく適合できたようで、他の例を挙げると私の経験上になるがプログラミング言語の処理系もうまくマッチすると思う（残念ながら全く問題がない訳ではないが）。その他、経験上言えることは、一連の法則性を持った多様なものを処理するにはオブジェクト指向が向いていると考えられる。ほかの例を挙げると、実はオブジェクト指向ってしっくりこないんです！の記事にある、とりすけ さんのコメントで税金計算処理の適用事例があります。
以上、確かに適用できる事例はありますが、逆にいうと応用例はかなり限定されています。よく自称オブジェクト指向専門家に具体的な話を聞くと『息を吸うようにインタフェースを使っている』という分かったような分からないような返しをされますが、具体的な話ができないということはそもそも彼（彼女）も分かっていないということになるでしょう。本当に息を吸うようにインタフェースを使っているのなら具体例が多数出てくるでしょう。

また、オブジェクト指向の本質はメッセージだ！という人もいらっしゃいます。なるほどメッセージをやり取りすることにより複雑なシステムを簡単に構築しようということらしいです。では以下の２つのコードはどちらが理解しやすいでしょうか？

z = 3 * x * y + 4 * x + 6 * y + 2;

z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2);

『下のコードの方が良い』という人はぜひリハビリを行ってください。少なくとも人前では上の方がよいと言いましょう。ちなみに当たり前ですが、これを持ってオブジェクト指向がダメだと言いたい訳ではなく、言いたいことは、『メッセージというある種のプログラムを抽象化する道具も乱用すると却って悪戯にプログラムを複雑にする』ということです。
次の回（おそらく来週？）このメッセージについて考察したいと思います。