メッセージ。 - にゃー

メッセージパッシング方式でコードを書いたことはないけど、理屈は別に間違っていると思わない。それが機能しない、ファンタジーだというなら、どういう理屈でうまくいかないか説明しないと、アランケイに失礼だし、議論が広がらないんじゃないかな？

個人的には、メッセージパッシング自体はオブジェクトが自身の内部状態と外部IOに責任を持つという考え方を別の言葉で表現した自然な見方のように思う。つまりそれは、各プログラマがコーディングする際にプログラム全体を把握していなくてもよくて、プログラムの一部の構造だけ理解していればいいということだ。

たとえば、アセンブリ言語でコーディングしていると、変数やルーティンはすべてグローバルなのでプログラマが手動でケアする必要があるし処理はGOTO文で書かなきゃいけず、壮大なパズルになる。でもこれだと大きなプログラムで整合性をつけるのが大変だし、複数人のプログラマで分業がしにくい。そしてダイクストラがGOTO文は有害だと言って、構造化プログラミングが普及していった。

で、C言語のような手続き型プログラミングの時代になるわけだけど、これによりプログラマーは、あるプログラムの全貌を子細に把握していなくてもプログラムをできるようになった。つまり、楽になったし、分業もしやすくなったわけだ。プログラムを構造に分解して、各部分を完成させれば、総体としてプログラムが動くはずなのだから。

ただ、C言語なんかではまだグローバルに生きる変数を強く意識しなきゃいけなかったし、アセンブリ言語でコードを書いていたときのような、プログラムの処理の流れの子細な把握、詳細仕様レベルの理解という仕事は、依然として各プログラマに課されていた（アセンブリよりかなり楽になったとはいえ）。その点を改善しより構造化を推し進めたのがオブジェクト指向の少なくとも一面といえるだろう。

プログラム全体の詳細仕様を知らなくても、ある機能ブロックの内部と外部とのインタフェース仕様を正確に理解していればその機能ブロックを改修できる、オブジェクト指向によってもたらされた一つの恩恵だ。ただし、ただオブジェクト指向言語を使えばこの恩恵が受けられるわけではない。構造化プログラミングの考え方に反するクラスをまたがるグローバル変数や、(不必要な)副作用を伴うメソッドを定義・使用しないようにしなければならない。

そうすれば、あるオブジェクト（クラス）の内部（プラス外部とのインタフェース）だけ見ていればプログラミングができるようになる。プログラムを抽象的に見られる人からすれば、これはメッセージパッシングに他ならない。

こうした構造化によるプログラム可能領域の可視化は、関数型プログラミングでも主要な話題だが

テスト

--047d7bdc0d9ee796ec04fed539a3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

44OG44K544OIMg0K
--047d7bdc0d9ee796ec04fed539a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PHAgZGlyPSJsdHIiPuODhuOCueODiDI8L3A+DQo=
--047d7bdc0d9ee796ec04fed539a3--