オブジェクト指向 アラン・ケイのオブジェクト指向とは

ウィキペディア

オブジェクト指向

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/04/02 03:16 UTC 版)

アラン・ケイのオブジェクト指向とは

1980年代の言及

1989年に発表された「User Interface A Personal View」という記事の中でアラン・ケイは、Smalltalkのオブジェクト指向性は大変示唆的であると前置きした上で、そのプログラミング言語でのOOPと、そのGUIフレームワークでのOOUIを照応させながらこう述べている。これは人とコンピュータの対話形式としてのオブジェクト指向に沿ったものになっている。1970年代から80年代にかけてのオブジェクト指向は、GUI（グラフィカルユーザーインターフェース）と半ば表裏一体で扱われていたという技術史背景がある。

object-oriented means that the object knows what it can do.
（オブジェクト指向とは、オブジェクトが出来る「なにか」を知っていることを意味している）

これは認知心理学のアフォーダンスにつながる考え方と解釈されている。その説明の中でケイは、Smalltalkプログラミングを抽象シンボル舞台と形容しており、GUIフレームワークを具象ユーザーインターフェース舞台と形容している。前者の抽象シンボル舞台では、我々は最初にオブジェクトの名前（識別子）をコーディングし、次にそのオブジェクトが実行する「なにか」を伝えるメッセージをコーディングすることになる。後者の具象ユーザーインターフェース舞台では、我々は最初に操作する対象（アイコン）を選択し、次にその対象が提供する「なにか」のメニュー欄を表示選択することになる。この双方を踏まえた上でケイはこう結論している。

In both case we have the object first and the desire second. this unifies the concrete with the abstract in highly satisfying way.
（双方の事例において私達は、オブジェクト（対象）を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する）

80年代前半までのオブジェクト指向はプログラミングとGUIの融合思想と言った方が適当であり、オペレータがプログラミングでカスタマイズした結果をGUIビュー環境でほぼ同時に確認できるという特性は、コマンドライン実行とキャラクタ文字環境が当然であった時代において革新的であった。プログラミングはコンピュータとの潜在的な対話であり、GUIは顕在的な対話であると形容されている。長じてアイコン選択とメニュー処理を適宜に連携させるGUIの考え方をプログラミングにも応用したものが、後述のオブジェクトとメッセージ式になっている。

1990年代の言及

1992年にACMからプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌93年の「The Early History Of Smalltalk」でオブジェクト指向の原点としてのSmalltalkについて解説している。冒頭の序章で設計理念が説明され、第一章から第三章まではその着想元になったバロースB5000、Sketchpad、Simula、Flex machine、LISPなどの技術史が記され、第四章から第六章まではSmalltalkの開発史が綴られている。ここでは序章から特徴的な要点のみを抜粋する。

Smalltalk's design—and existence—is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages.
（Smalltalkの設計―及び存在―とは、私たちの思い描ける全てが、自己の状態とプロセスの結合を内部隠蔽した個々の振る舞い組立ブロックの再帰構成によって表現され、徹底的なメッセージの交換のみによって処理されるということだ。）

再帰構成すなわち再帰の概念は、後続文にも繰り返し登場している。もっとも再帰は一般知識であり、例えばジョン・マッカーシーもLISPの設計をrecursive functions of symbolic expressions and their computation by machine.（記号式の再帰関数群と機械によるその計算）と概略していた。メッセージ交換は、徹底的な疎結合および情報隠蔽を示唆している。

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer.
（Smalltalkは計算概念の自己再帰である。コンピュータプログラムをその全体からの劣化要素―データ構造、手続き、関数といった言語機能の諸々に分割していくのではなく、Smalltalkのオブジェクトはそれぞれが計算の総体可能性を備えた再帰要素になる。）

ケイが理想とする計算の総体可能性の反対である劣化要素への分割とは、いわゆる型システムの導入を指している。他の論考でもケイは特に静的な型システムに対して否定的な見解を示していた。

Philosophically, Smalltalk's objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealizations of concepts—Ideas—from which manifestations can be created.
（哲学面でのSmalltalkオブジェクトは、ライプニッツのモナドや20世紀の物理・生物学思考との共通点を見出せる。オブジェクトの構築は、イデアから現象が創生されるという全くのプラトニックである。）

第四章では、Smalltalkの言語仕様が六つに概略されている。

1, EverythingIsAnObject.

2, Objects communicate by sending and receiving messages (in terms of objects).

3, Objects have their own memory (in terms of objects).

4, Every object is an instance of a class (which must be an object).

5, The class holds the shared behavior for its instances (in the form of objects in a program list).

6, To eval a program list, control is passed to the first object and the remainder is treated as its message.

この和訳は以下のようになるが、ここでは長い説明を避けて特徴的な要点のみを解説する。

1. すべてはオブジェクトである。
2. オブジェクトはメッセージの送信と受信によってコミュニケーションする。
3. オブジェクトは自身の記憶を持つ。
4. すべてのオブジェクトはクラスのインスタンスである。クラスもまたオブジェクトである。
5. クラスはその各インスタンスで共有される振る舞いを保持する。振る舞いとはプログラムリスト・オブジェクトである。
6. プログラムリストの評価では、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。

(2)は様々に解釈されるが、コミュニケーションするオブジェクトは、プロセスやアクターとしての性格が強くなる。(3)の記憶は簡単に言うとフィールドやプロパティや属性であるが、オブジェクトの振る舞いを制約するための私的環境を示唆している。(4)は、クラスもまたメタクラスのインスタンス化であるという再帰構成を示唆している。(5)の振る舞いは簡単に言うとメソッドであるが、LISPのフォームリストに似たオブジェクトとして保持されることを示唆している。(6)は、式内のオブジェクトはその時の並べられた順序によって、いずれもがコントローラ（関数式）になり、いずれもがそれへのメッセージ（引数）になることを示唆している。

2000年代の言及

2003年にアラン・ケイはオブジェクト指向の貢献でチューリング賞を受賞し、知人から改めてオブジェクト指向の意味を尋ねられたケイは以下のようにメール返信している。このメールは60年代末からの構想をさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋していく。

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.
（さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによってコミュニケーションする存在、僕はオブジェクトをそう考えている）

上記はケイ本来のオブジェクトの在り方を述べたものであり、特に解説はしない。

I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, ...
（僕はデータを取り除きたかった。これをバロースB5000は驚くべきHWアーキテクチャでほとんど実現していた。僕は気付いた。細胞/全体コンピュータメタファはデータを除去できるであろうと、）

ここでプログラムからデータを取り除きたいという考えが提示されている。

My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful.
（僕の数学専攻経験がこれを気付かせた。各オブジェクトは幾つかの関連付けられた代数を持ち、またその系統群もあるかもしれない。それらは大変有用になるだろうと）

ここでの代数は、プロセス代数か、プログラミングに適用した代数的構造とも解釈できる。

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
（僕にとってのOOPとは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった）

メッセージングは造語に近く、メッセージパッシングに類似の概念であり、ただのリモートプロシージャコールとは異なることが明言されている。ステートプロセスは、データとコードの一元化概念であり、これも造語である。遅延バインディングは、シンボルと実体の結合をランタイムで決定する概念である。

One of the things I should have mentioned is that there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play.
（僕が触れるべきだった一つは、Simulaを触媒にした二本の道があったということだ。最初の一本はバイオ/ネットな非データ手順で僕が選んだ方。少し遅れたもう一本は抽象データ型でこっちの方がずっと賑わっている）

ここで抽象データ型に対しての、非データ手順（non-data-procedure）というワードが登場する。振る舞いを通してデータを扱うというデータ抽象の概念を、更に抽象化したものが非データであり、代数学で言う写像だけでデータを表現するという概念を指している。これにケイの生物学専攻を背景にしたバイオ/ネット（bio/net）なる考えが加えられている。

And the very first problems I solved with my early Utah stuff was the "disappearing of data" using only methods and objects. At the end of the 60s (I think) Bob Balzer wrote a pretty nifty paper called "Dataless Programming", and shortly thereafter John Reynolds wrote an equally nifty paper "Gedanken" (in 1970 I think) in which he showed that using the lamda expressions the right way would allow data to be abstracted by procedures.
（ユタでの専攻知識で僕が解決した最初期の問題はメソッドとオブジェクトのみを用いてのデータの消滅だった。1960年代末にBob Balzerはデータレス・プログラミングというものを書き示した。直後の1970年にJohn Reynoldsはラムダ式を用いての手順によるデータ抽象化の方法を書き示した）

非データ手順（non-data-procedure）に関連付けられるものとしては、代数的構造、圏論の射や関手の構造、Futuresとpromises、ポイントフリースタイル、プロセス代数、アクターモデル、自由モナドなどが挙げられる。

The people who liked objects as non-data were smaller in number,
（非データとしてのオブジェクトを好む者は少なかった、）

ここで歴史に戻る。1970年前後になるとソフトウェア危機としても語られるプログラム規模拡大に対応するために、サブルーチンとデータをまとめたプログラムモジュールという機能が登場した。それと同時期の1967年にオルヨハン・ダールらはクラスという機能を備えたSimula67を開発し、1969年からエドガー・ダイクストラは抽象データ構造という概念を備えた構造化プログラミングを提唱した。1974年からIBM社中心の研究者たちが構造化分析/設計と総称される技法を発表し、構造化プログラミングはこちらに取って代わられた。1972年からアラン・ケイはメッセージングという概念を備えたオブジェクト指向を誕生させている。オブジェクト指向は後にクラス・パラダイムにマウントされている。

構造化設計は、サブルーチン複合体とデータ構造を扱っている具象データ（concrete data）技術である。Simula発のクラスとダイクストラ発の抽象データ構造は、プログラムモジュールにカプセル化・継承・多態性を備えて抽象体として扱おうとする抽象データ（abstract data）技術である。そしてアラン・ケイ本来のオブジェクトとは、プログラムモジュールを生物学と代数学の観点から再解釈した非データ（non data）技術であった。構造化開発は1980年代までの主流であり、続けてオブジェクト指向が主流になったが、現在においてもクラスをただのデータとメソッドの複合体として扱っているようなオブジェクト指向は、構造化開発と大差ないものになり「具象データ」から「抽象データ」への思考転換の難しさを物語っている。モジュールの抽象化が提唱され始めたのは1970年代であったが、同時期にアラン・ケイは「抽象データ」を更に抽象化した「非データ」を構想していた。

2020年の言及

Q&AサイトのQuoraで「1966～67年のオブジェクト指向という造語を発したアラン・ケイに誰かが影響を与えていたのか？」という質問に対して本人がこう回答している。なお、強調されている“rotation”は「The Early History of Smalltalk」などにその経緯が記された1966年頃の彼自身による“オブジェクト”の、特にソフトウエアの基本構成単位としての発見（念のため、この時点ではSimulaはまだ「オブジェクト」ではなく後述のように相当するエンティティを「プロセス」という用語で表現していた）とその後の彼の中での発想の大転換を意味する。

In the 1960s, software composites that were more complex than arrays, were often called “objects”, and all the schemes I had seen involved structures that included attached procedures. A month or so after the “rotation” someone asked me what I was doing, and I foolishly said “object-oriented programming”.
（60年代、配列より複雑なソフトウェア構成体はしばしばオブジェクトと呼ばれており、僕のスキームにあった手続き付きの構造体もそうだった。私の中での“発想の転換”が起こった後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。）

The foolish part is that “object” is a very bad word for what I had in mind — it is too inert and feels too much like “data”. Simula called its instances “processes” and that is better.“Process-oriented programming” would have been much better, don’t you think?
（愚かしいこのオブジェクトは僕の考えを表現するのにとても悪い言葉だった。不活性的でデータを過剰に意識させたからだ。Simulaはプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい？）