Elixir中の人ツイートオブジェクト指向とは何だったのか?このブログでも何度か取り上げているように、プログラミングにおけるここ数年間のトレンドで最も大きなものは、関数型プログラミングの隆盛だと言って良いだろう。そのトレンドと共に相対的に存在感を失いつつあるのが、それまで長らく主流を占めていた「オブジェクト指向」という考え方である。関数型プログラミングの観点から眺めると、オブジェクト指向プログラミングではシステムの状態を暗黙に扱う(情報隠蔽)ために実行時の挙動が予測しづらくなり、高度な並行性が求められる現在の環境では、信頼性を確保する際の大きな障害となるように見える。筆者も含めて、オブジェクト指向という考え方にあれだけ熱狂した立場から考えると、昨今のオブジェクト指向に対する評価に対して若干の違和感を感じざるを得ないのも事実である。いうわけで今回は、オブジェクト指向の発案者による発言を参照しながら、改めて「そもそもオブジェクト指向とは何だったのか?」ということについて考えてみたい。始めに「オブジェクト指向」という言葉の意味については、どこかに正式な定義が存在する、というわけではないようだ。これは「関数型」についても同様のようである。このブログで書かれていることはある種の解釈や立場表明をしているに過ぎないということに注意して頂きたい。メッセージング「オブジェクト指向(object-oriented)」という言葉を最初に提唱したのは、Smalltalkというオブジェクト指向環境を発明したアラン・ケイ氏だと言われている(これは本人も認めている)。(強調は筆者)そのアラン・ケイ氏によれば、オブジェクト指向で最も重要なのは「メッセージング」なのだと言う。(強調は筆者)上記引用にもあるように、ケイ氏は「オブジェクト(指向)」という言葉を持ち出したことに後悔さえしていると言う。メッセージングの観点から言えば、クラスやオブジェクトさえも重要ではないということから、本来は「メッセージ指向」と呼ぶべきだったのかもしれない。オブジェクト指向を実践してきた多くのプログラマにとっては、むしろ馴染みの薄いものではないだろうか。ケイ氏は、オブジェクトを、ネットワークを形成してメッセージを送り合うコンピュータのメタファーとして捉えており、インターネット上のサーバーのように、リクエストをメッセージとして受け取り、そのメッセージをサーバー側で解釈して何らかの処理を行うというモデルを想定していた。メソッド呼び出しがメッセージングに相当するように思われるかもしれないが厳密には異なる。このメッセージを非同期にやり取りするという、今まさに広がりを見せつつある並行処理のモデルを70年代の段階で実現していた(後にアクターモデルと呼ばれる)。[2016/05/09追記]この部分に事実誤認があるとの指摘をコメント欄にて頂いた。ケイのメッセージングとはまた別物です。Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。コメント欄(sumimさん)よりとのこと。ご指摘感謝![2016/05/10追記]さらに別の方からコメントを頂く。Hewittの考案であり、Kayのメッセージングとは「別物」ということですが、歴史はしばしばもうちょっとややこしいものです。Modelの着想を得た、という経緯もあります。Kayの名前があるもの、それ以上のクレジットがなかったために、Carlが「コミュニティー」からもうちょっとアイディアの出典を正直に述べなくてはならないという批判を受けることになったという話もあります。入門も是非ご参考あれ。このメッセージングに関係して、最近タイムリーなブログ記事を見かけた。アラン・ケイ氏のオブジェクト指向を体現している言語環境なのではないかという考察である。ちなみに、この二つの言語は一般的には関数型プログラミング言語として認識されているはずである。オブジェクト指向に近い言語である」という趣旨の発言をしているようだ。それは、メッセージングという仕組みの内に、ケイ氏が考えるオブジェクト指向の要点が全て含まれているからである。ケイ氏は、メッセージングの位置づけを日本語の「間」という言葉で説明しているが、氏によれば、システムの「間」つまりコミュニケーションに着目することによって、システムにとって重大な目的(ゴール)だけを表現し、その他の詳細については二次的に決定すれば良い、そしてそのような決定の先送りがシステムの寿命を延ばす鍵になるのだと言う。メッセージがどのように解釈されるのか、クラスから作られたオブジェクトによって処理されるのか、そのクラスは継承によって構造を共有しているのか、あるいはプロトタイプベースなのかという問題は全て二次的な問題である。ある段階からあらゆることを決定し固定化したがる人たちによって不毛な議論が繰り返され、その結果、進歩が停滞しているとケイ氏は苛立ちを見せていた。progress」の考え方は、21世紀になってから普及したアジャイルの考え方そのものである。アジャイルはオブジェクト指向のコミュニティが生み出したものであるが、その考え方の源流はオブジェクト指向の始まりから既に埋め込まれていた。抽象データ型ここまでの話で、オブジェクト指向の発案者であるアラン・ケイ氏の、メッセージングという真意が明らかになった。これだけでは職業プログラマの多くが実践してきたオブジェクト指向らしきものは一体何だったのかという疑問が残る。route」の他に、「抽象データ型」を中心に据える流れも起こり、こちらの方がむしろその後主流になったと説明している。typing)として職業プログラマの間では主流になった。mind”」)、型システムそのものについて否定的に見ているわけではないようである。Programming”クリエイティビティさて、結果的に抽象データ型が主流になったのあれば、それがいわゆる多くの人が認識するところのオブジェクト指向なのだから、今更「アラン・ケイ氏のオブジェクト指向」についてわざわざ考慮する必要があるのかと考える人もいるかもしれない。筆者にとってこの二つの立場の違いは、単にプログラミング言語の差異に留まらず、コンピューティングというものに対する立場を二分する大きな断絶を象徴する分岐であるように思えるのである。抽象データ型というのは、単にプログラミング言語の問題である。システム開発者側の問題だと言っても良いかもしれない。開発側の観点から仕事上のトラブルを少なくするといった、よりプラグマティックな理由から型システムという仕組みを評価できるだろう。職業プログラマの間で型システムが普及した理由にはこのような側面もあったのではないだろうか。Smalltalk」を読むと、オブジェクト指向は単にプログラミングだけの問題ではなく、もっと壮大な理想を追求するために考案されたのだということが分かる。Smalltalkhttp://worrydream.com/EarlyHistoryOfSmalltalk/オブジェクト指向が生まれる直前の60年代という時代は、コンピュータが、予め計画された計算を行うだけというイメージの、一つの部屋を専有する巨大な機械から、もっと人間の力を高める形でインタラクションを提供する新しいメディアへと生まれ変わろうとする、いわゆるパーソナルコンピューティングの黎明期に当たる。Agency)というアメリカ国防総省管轄の研究機関である。開発したことでも知られる。構想であり、この構想には今日では当たり前になっているパーソナルコンピュータやネットワーク、GUI(ウィンドウシステム)など、パーソナルコンピューティングにとって重要なあらゆる要素が詰め込まれていた。reach」)ということであったが、これは言い換えれば「クリエイティビティ(創造性)」の追求である。ケイ氏が最も熱心に取り組んでいたのはコンピュータを使った子供の教育であった。オブジェクト指向プログラミングを子供に教えることによって、ソフトウェアを自身の問題に合わせて自在に変更出来るようにし、より高い問題解決能力を獲得させることを目指した。この教育プロジェクトの試行錯誤によって得られた知見には大変興味深いものが多い。クリエイティビティに寄与する一つの根拠として、より少ない原則で多くを表現できるというものがある。object」というやつである。message」と言ったかもしれない(そのようなプログラミング言語が実際に存在する)。この全てがオブジェクトであるという原則と、大きなシステム(オブジェクト)は小さなシステム(オブジェクト)の組み合わせで作られるという「再帰的デザイン」によって、どんな複雑なシステムをデザインするときでも、覚えなくてはならない原則は少なくて済むようになる。おいて重要なのは、システムを使うという行為と作るという行為が全く同じになるということである。システムを使うときと全く同じ操作で、その延長線上でシステム自体を変更することができる。このように、導入において覚えることが少なくて済む、そしてその少ない道具立ててであらゆることが表現できるという枠組みが、子供の教育にとって重要であることは想像に難くない。実際に試してみて分かったことは、あるオブジェクトにメッセージを送るという1ステップの変更については小さな子供でも理解することが出来るが、複数ステップの変更を組み合わせないと解決できないような問題になると、それがほんの2、3ステップだったとしても極めて難しくなってしまうということだった。これは子供だけでなく、プログラミング経験のない大人でも似たような現象が見られたようである。初歩の問題は容易にクリアできるが、問題が複雑化すると、それがプログラマから見たら些細だと思われる問題でも全く歯が立たなくなる。これは今で言うプログラムデザインの問題である。templates」という仕組みを考案した。これはぼんやりとしたデザインのアイデアとプログラムによる実例の中間に位置する道具立ててで、今で言うところのデザインパターンやフレームワークに相当するものである。progress」にすることの重要性について繰り返し語っているが、それはいかに多くの技術者や専門家が手段に埋没し、そして宗教論争に明け暮れているかということに対しての警鐘にもなっている。Smalltalk」の一つのハイライトは、1979年、ケイ氏の勤めるパロアルト研究所(PARC)に、あのスティーブ・ジョブズ氏が訪れる場面である。プロジェクトを立ち上げていたが、決定的なアイデアがなく模索中の段階であった。ケイ氏は、PARCに訪れたアップルの面々に対して、ALTOというパーソナルコンピュータ試作機のデモを行う。搭載されており、その上ではウィンドウベースのGUIが動いていた。氏がその場で修正して訪問者を驚かせたという場面が紹介されている。環境の強力さが垣間見えるエピソードである。この邂逅の後の歴史は多くの人の知るところなのでここでは深追いしないが、1995年に行われたインタビューにおいて、ジョブズ氏がパロアルト研究所で見たデモについて、そしてその当時は理解出来なかったというオブジェクト指向の重要性について語っているので、その動画を紹介しておきたい。この映像は放送後に一度紛失したと思われたマスターテープがジョブズ氏の死後に偶然見つかったということで、95年の放送時はカットされた部分も含めて全編放送されたものであるが、その内容にはただひたすら圧倒されるのみである。現在オブジェクト指向についてその起源から検討してみたが、この歴史を前提に改めて考えてみると、昨今言われる「オブジェクト指向から関数型へ」という話が大分狭い領域の話であることに気づかされる。モジュールシステムの進化という観点から言えば、関数型プログラミングが有効である場面が増えているのは疑いようがない。large」という形で適材適所に住み分けることになるのではないだろうか。binding)と言ったコンセプトは形を変えてあらゆる場面で見かけるようになった。その代表的なものの一つが、アジャイルという考え方である。オブジェクト指向はその出自から考えても分かるように、より上流の考えを重視する目的指向のパラダイムである。アジャイルはその後、経営やデザインなど、ソフトウェア開発の枠組みを超えて、クリエイション一般に適用出来るような普遍的な考え方として普及しつつある。AMメッセージパッシングは、プログラミングにおいて好きな概念のひとつです(ふだんのプログラミングにはあまり反映できてないですが)。カーネルの世界での(メッセージ重視という意味での)オブジェクト指向に似た概念として、マイクロカーネルがありますね。Dynabookほどの壮大さはないかもしれませんが。Hurdができて、普及したらおもしろいんだけどなあ。AM武藤さん、どうもご無沙汰です。Xも、BSDサブシステムやファイルシステム、ネットワークなどをカーネル空間に統合しており、純粋なマイクロカーネルから離れた実装になっている。」という情報を見つけて、そうだったのかあ、と感心しているところです。メッセージ指向的な高いモジュール性を備えたマイクロカーネルが結果的に普及しなかった経緯はとても興味深いですね。Oxymoron?」という文章も参考になるかもしれません。通じ、メッセージングというメタファにより目指した「レイトバインディングの徹底」という試みについての彼なりの総括のような文章になっているように思えて興味深いです。(後にアクターモデルと呼ばれる)。ありますが、この説明はちょっと誤解を招きそうで心配です。ケイのメッセージングとはまた別物です。Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。PMsumimさん、コメントを頂きまして大変光栄に思います。Oxymoron?」ありがとうございます。今回の件を調べるに当たってタイトルだけはちらっと見かけていたのですが未読でした。この説明はちょっと誤解を招きそうで心配です。Smalltalk(-72、-74、-76、-78)は非同期のメッセージングベースで実装されたことはありません。ご指摘の件を追記しておきたいと思います。ような処理系を含めて一般化出来ると思っていましたが、Smalltalkについては非同期のメッセージングベースで実装されたことがないということであれば、それにはちょっと無理がありそうですね。Hewittの考案であり、Kayのメッセージングとは「別物」ということですが、歴史はしばしばもうちょっとややこしいものです。Modelの着想を得た、という経緯もあります。Kayの名前があるもの、それ以上のクレジットがなかったために、Carlが「コミュニティー」からもうちょっとアイディアの出典を正直に述べなくてはならないという批判を受けることになったという話もあります。AMヒューイットは、Smalltalk-71(PLANNERなどに影響を受けてケイが考えた言語。)など、ケイのメッセージングと彼のアクターの関係について、なにかと混乱を生じさせる人なのですね。加えてひとくくりに論じるのは、お気づきのとおり、ちょっと無理がありそうですね。触れてみるのがいちばんかと思います。いえどもケイのメッセージングを純粋に体験することが難しくなっていることが懸念されます。エミュレーターが2種類あるので、参考まで以下にご紹介します。推奨)で動作するこちらです。コードを記述するためによく用いる特殊記号の一部やマウスポインタを使った定義済みクラスの編集を行なう組み込みのエディタが現状では使えないなど、後述の別のエミュに比べてかなり制約があります。処理系が使えるようになります。