コンテンツにスキップ

「オブジェクト指向」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Apple改名に伴う変更
(同じ利用者による、間の2版が非表示)
4行目: 4行目:
== オブジェクト指向の来歴 ==
== オブジェクト指向の来歴 ==
[[ファイル:Alan Kay (3097597186) (cropped).jpg|サムネイル|222x222ピクセル|Alan Kay]]
[[ファイル:Alan Kay (3097597186) (cropped).jpg|サムネイル|222x222ピクセル|Alan Kay]]
オブジェクト指向(''object-oriented'')という言葉自体は、1972年から80年にかけてプログラミング言語「[[Smalltalk]]」を開発した[[ゼロックス|ゼロックス社]][[パロアルト研究所]]の計算機科学者[[アラン・ケイ]]がその言語設計を説明する初めてみ出されている<ref name="EarlyHistoryOfSmalltalk">{{Cite web|url=http://worrydream.com/EarlyHistoryOfSmalltalk/|title=The Early History Of Smalltalk|accessdate=2019-01|publisher=}}</ref>。本人の述懐によると、大学院時代のケイがプログラミング言語「[[Simula]]」に感化されて日夜プログラミング・アーキテクチャの思索に耽っていた1967年頃、今何をしているのかと尋ねてきた知人に対して「''object-oriented programming''だよ」と咄嗟の造語で答えたのが発端だという。このオブジェクト指向が知名度を得るようになったのは1981年頃からであり、当時のマイコン専門誌[[バイト (雑誌)|BYTE]]によるSmalltalkの誌上紹介が契機になっている。オブジェクト指向の中でケイ自身は[[メッセージング]]という考え方を重視していたが、世間の技術的関心は[[クラス (コンピュータ)|クラス]]と[[インスタンス]]の仕組みの方に集まり、オブジェクト指向の解釈はケイの考えとは異なる方向性で推移していった。[[クラス (コンピュータ)|クラス]]を初めて導入した言語はSimulaの1967年版だったので、こちらも後付けでオブジェクト指向の源流に位置付けられている<ref>[http://kristennygaard.org/FORSKNINGSDOK_MAPPE/F_OO_start.html How Object-Oriented Programming Started]</ref>。Simulaに結び付けられたオブジェクト指向と、Smalltalkで提唱されたオブジェクト指向の性格は全く異なるものだったので、双方の解釈に数々の齟齬を生じさせている<ref>{{Cite web|url=https://www.cs.cmu.edu/~charlie/courses/15-214/2014-fall/slides/25-history-oo.pdf|title=OO History: Simula and Smalltalk|accessdate=2019-02|publisher=}}</ref>。1983年に計算機科学者[[ビャーネ・ストロヴストルップ]]がSimulaのオブジェクト指向をモデルにした言語「[[C++]]」を公開し、このC++が人気を博した事でオブジェクト指向は本来のSmalltalkではなく、後付けのSimulaスタイルの方で認識されるようになった。
オブジェクト指向(''object-oriented'')という用語自体は、1972年から80年にかけてプログラミング言語「[[Smalltalk]]」を開発した[[ゼロックス|ゼロックス社]][[パロアルト研究所]]の計算機科学者[[アラン・ケイ]]がその言語設計を説明する過程ている<ref name="EarlyHistoryOfSmalltalk">{{Cite web|url=http://worrydream.com/EarlyHistoryOfSmalltalk/|title=The Early History Of Smalltalk|accessdate=2019-01|publisher=}}</ref>。本人の述懐によると、大学院時代のケイがプログラミング言語「[[Simula]]」に感化されて日夜プログラミング・アーキテクチャの思索に耽っていた1967年頃、今何をしているのかと尋ねてきた知人に対して「''object-oriented programming''だよ」と咄嗟の造語で答えたのが原点であるという。このオブジェクト指向が知名度を得るようになったのは1981年頃からであり、当時の著名なマイコン専門誌[[バイト (雑誌)|BYTE]]によるSmalltalkの誌上紹介が契機になっている。オブジェクト指向の中でケイ自身は[[メッセージング]]という考え方を重視していたが、世間の技術的関心は[[クラス (コンピュータ)|クラス]]と[[インスタンス]]の仕組みの方に集まり、オブジェクト指向の解釈はケイの考えとは異なる方向性で推移していった。[[クラス (コンピュータ)|クラス]]を初めて導入した言語はSimulaの1967年版だったので、こちらも後付けでオブジェクト指向の源流に位置付けられている<ref>[http://kristennygaard.org/FORSKNINGSDOK_MAPPE/F_OO_start.html How Object-Oriented Programming Started]</ref>。Simulaに結び付けられたオブジェクト指向と、Smalltalkで提唱されたオブジェクト指向の性格は全く異なるものだったので、双方の解釈に数々の齟齬を生じさせている<ref>{{Cite web|url=https://www.cs.cmu.edu/~charlie/courses/15-214/2014-fall/slides/25-history-oo.pdf|title=OO History: Simula and Smalltalk|accessdate=2019-02|publisher=}}</ref>。1983年に計算機科学者[[ビャーネ・ストロヴストルップ]]がSimulaのオブジェクト指向をモデルにした言語「[[C++]]」を公開し、このC++が人気を博した事でオブジェクト指向は本来のSmalltalkではなく、後付けのSimulaスタイルの方で認識されるようになった。


1986年から[[Association for Computing Machinery|ACM]](計算機協会)が[[OOPSLA]](オブジェクト指向会議)を年度開催するようになり、オブジェクト指向は[[コンピュータサイエンス]]の一つのムーブメントになった。[[OOPSLA]]初期のチェアパーソンは、[[Smalltalk]]が生まれた[[ゼロックス|ゼロックス社]][[パロアルト研究所]]のフェローが務めることが多かった。Smalltalkは正確にはプログラミング言語と[[グラフィカルユーザインタフェース|GUI]]運用環境を合わせた[[フレームワーク]]であり、[[Alto|ゼロックスAlto]]機上の[[オペレーティングシステム|OS]]または[[ミドルウェア]]として開発されていた。Smalltalkは70年代の[[アラン・ケイ]]が構想していた[[ダイナブック]]のための[[グラフィカルユーザインタフェース|GUI]]環境でもあった。[[ダイナブック]]はパーソナルコンピュータの原型に位置付けられているものである。[[Alto|ゼロックスAlto]]は[[GUI]]を初めて汎用的にサポートしたコンピュータと[[オペレーティングシステム|OS]]であり、かの[[スティーブ・ジョブズ|スティーブ・ジョブス]]を啓発して[[Macintosh]]のモデルになったことはよく知られている。こうした背景からオブジェクト指向は、上述のプログラミング云々よりも、[[グラフィカルユーザインタフェース|GUI]](グラフィカル・ユーザー・インターフェース)を始めにした当時の先進的な[[ソフトウェア設計|ソフトウェアデザイン]]と[[ソフトウェアアーキテクチャ]]のための開拓的なモデル理論として受け止められる方が好まれた。[[データベース]]開発と[[オペレーティングシステム]]開発および[[ユーザーインターフェース]]設計が最初の活用対象になり、産業プログラミング界隈の主流であった[[構造化プログラミング|構造化]](Structured)分野に倣うようにして、オブジェクト指向設計(OOD)オブジェクト指向分析(OOA)[[オブジェクト指向モデリング]](OOM)といった科目も立ち上げられた。それらの研究は[[形式手法]]の確立に繋げられて1991年に[[Booch法|ブーチメソッド]]と[[オブジェクトモデル化技法]]、1992年に[[オブジェクト指向ソフトウェア工学]]が発表され、いずれも[[形式言語]]化されていたのでオブジェクトモデリング言語という総称用語を生み出した。上記三種の考案者([[スリーアミーゴス]])は、後のIBMブランドになる[[ラショナル|ラショナルソフトウェア]]で合流して[[統一モデリング言語]](UML)を構築するに到り、1995年のOOPSLAで初回発表した。[[デザインパターン (ソフトウェア)|デザインパターン]]、[[リファクタリング (プログラミング)|リファクタリング]]、[[モデル駆動工学]]、[[ドメイン固有言語]]、[[アジャイルソフトウェア開発]]といった数々のトピックも[[OOPSLA]]から誕生している。
1986年から[[Association for Computing Machinery|ACM]](計算機協会)が[[OOPSLA]](オブジェクト指向会議)を年度開催するようになり、オブジェクト指向は[[コンピュータサイエンス]]の一つのムーブメントになった。[[OOPSLA]]初期のチェアパーソンは、[[Smalltalk]]が生まれた[[ゼロックス|ゼロックス社]][[パロアルト研究所]]のフェローが務めることが多かった。Smalltalkは正確にはプログラミング言語と[[グラフィカルユーザインタフェース|GUI]]運用環境を合わせた[[フレームワーク]]であり、[[Alto|ゼロックスAlto]]機上の[[オペレーティングシステム|OS]]または[[ミドルウェア]]として開発されていた。Smalltalkは70年代の[[アラン・ケイ]]が構想していた[[ダイナブック]]のための[[グラフィカルユーザインタフェース|GUI]]環境でもあった。[[ダイナブック]]はパーソナルコンピュータの原型に位置付けられているものである。[[Alto|ゼロックスAlto]]は[[GUI]]を初めて汎用的にサポートしたコンピュータと[[オペレーティングシステム|OS]]であり、かの[[スティーブ・ジョブズ|スティーブ・ジョブス]]を啓発して[[Macintosh]]のモデルになったことはよく知られている。こうした背景からオブジェクト指向は、上述のプログラミング云々よりも、[[グラフィカルユーザインタフェース|GUI]](グラフィカル・ユーザー・インターフェース)を始めにした当時の先進的な[[ソフトウェア設計|ソフトウェアデザイン]]と[[ソフトウェアアーキテクチャ]]のための開拓的なモデル理論として受け止められる方が好まれた。[[データベース]]開発と[[オペレーティングシステム]]開発および[[ユーザーインターフェース]]設計が最初の活用対象になり、産業プログラミング界隈の主流であった[[構造化プログラミング|構造化]](Structured)分野に倣うようにして、オブジェクト指向設計(OOD)オブジェクト指向分析(OOA)[[オブジェクト指向モデリング]](OOM)といった科目も立ち上げられた。それらの研究は[[形式手法]]の確立に繋げられて1991年に[[Booch法|ブーチメソッド]]と[[オブジェクトモデル化技法]]、1992年に[[オブジェクト指向ソフトウェア工学]]が発表され、いずれも[[形式言語]]化されていたのでオブジェクトモデリング言語という総称用語を生み出した。上記三種の考案者([[スリーアミーゴス]])は、後のIBMブランドになる[[ラショナル|ラショナルソフトウェア]]で合流して[[統一モデリング言語]](UML)を構築するに到り、1995年のOOPSLAで初回発表した。[[デザインパターン (ソフトウェア)|デザインパターン]]、[[リファクタリング (プログラミング)|リファクタリング]]、[[モデル駆動工学]]、[[ドメイン固有言語]]、[[アジャイルソフトウェア開発]]といった数々のトピックも[[OOPSLA]]から誕生している。
26行目: 26行目:


=== 1980年代の言及 ===
=== 1980年代の言及 ===
1989年に発表された「User Interface A Personal View」という記事の中でアラン・ケイは、[[Smalltalk]]のオブジェクト指向性は大変示唆的であると前置きした上で、Smalltalkにおける「[[オブジェクト指向プログラミング|OOP]]と、[[GUI]]における「OOUIを照応させながらこう述べている<ref>{{Cite web|url=http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%20Personal%20View.pdf|title=User Interface A Personal View|accessdate=2020-1|publisher=}}</ref>。これは人とコンピュータの対話形式としてのオブジェクト指向に沿ったものになっている。{{Quotation|''object-oriented means that the object knows what it can do.''<br/>(オブジェクト指向とは、オブジェクトが出来る「なにか」を知っていることを意味している)|Alan Kay}}これは[[認知心理学]]の[[アフォーダンス]]につながる考え方と解釈されている。その説明の中でケイは、Smalltalkプログラミングを抽象シンボル舞台と形容しており、GUIアプリケションを具象ユーザーインターフェース舞台と形容している。前者の抽象シンボル舞台では、我々は最初にオブジェクトの名前(識別子)をコーディングし、次にそのオブジェクトが実行する「なにか」を伝えるメッセージをコーディングすることになる。後者の具象ユーザーインターフェース舞台では、我々は最初に操作する対象(アイコン)を選択し、次にその対象が提供する「なにか」のメニュー欄を表示させることになる。この双方を踏まえた上でケイはこう結論している。{{Quotation|''In both case we have the object first and the desire second. this unifies the concrete with the abstract in highly satisfying way.''<br/>(双方の事例において私達は、オブジェクト(対象)を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する)|Alan Kay}}
1989年に発表された「User Interface A Personal View」という記事の中でアラン・ケイは、[[Smalltalk]]のオブジェクト指向性は大変示唆的であると前置きした上で、そのプログラミング言語での[[オブジェクト指向プログラミング|OOP]]と、その[[GUI]]フレームワークでのOOUIを照応させながらこう述べている<ref>{{Cite web|url=http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%20Personal%20View.pdf|title=User Interface A Personal View|accessdate=2020-1|publisher=}}</ref>。これは人とコンピュータの対話形式としてのオブジェクト指向に沿ったものになっている。1970年代から80年代にかけてのオブジェクト指向は、GUI(グラフィカルユーザーインターフェース)と半ば表裏一体で扱われていたという技術史背景がある。
{{Quotation|object-oriented means that the object knows what it can do.<br/>(オブジェクト指向とは、オブジェクトが出来る「なにか」を知っていることを意味している)}}
これは[[認知心理学]]の[[アフォーダンス]]につながる考え方と解釈されている。その説明の中でケイは、Smalltalkプログラミングを抽象シンボル舞台と形容しており、GUIフレムワークを具象ユーザーインターフェース舞台と形容している。前者の抽象シンボル舞台では、我々は最初にオブジェクトの名前(識別子)をコーディングし、次にそのオブジェクトが実行する「なにか」を伝えるメッセージをコーディングすることになる。後者の具象ユーザーインターフェース舞台では、我々は最初に操作する対象(アイコン)を選択し、次にその対象が提供する「なにか」のメニュー欄を表示選択することになる。この双方を踏まえた上でケイはこう結論している。
{{Quotation|In both case we have the object first and the desire second. this unifies the concrete with the abstract in highly satisfying way.<br/>(双方の事例において私達は、オブジェクト(対象)を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する)}}

=== 1990年代の言及 ===
=== 1990年代の言及 ===
1992年に[[Association for Computing Machinery|ACM]]からプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌年の刊行記事でオブジェクト指向を六つ要約にまて説<ref name="EarlyHistoryOfSmalltalk" />。れは[[Smalltalk]]の言語仕様の概略でありいわゆるメッセージベースオブジェクト指向プログラミングの定義に沿ったものになっている。{{Quotation|1, ''EverythingIsAnObject.
1992年に[[Association for Computing Machinery|ACM]]からプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌年の「The Early History Of Smalltalk」でオブジェクト指向の原点しての[[Smalltalk]]につい説している<ref name="EarlyHistoryOfSmalltalk" />。冒頭の序章で設計理念が説明さ、第一章から第三章までその着想元になった[[バロース B5000|バロースB5000]]、[[Sketchpad]]、[[Simula]]、Flex machine、[[LISP]]など技術史が綴られ第四章から第六章まではSmalltalk開発史が記されている。ここでは長い説明を避けて序章から特徴的な要点のみを抜粋する。
{{Quotation|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.<br/>(Smalltalkの設計―及び存在―とは、私たちの思い描く全てが、自身のステートとプロセスの連携を内包した個々の振る舞い組立ブロックの再帰構成によって表現され、徹底的なメッセージの交換のみによって処理されるということだ。)}}ここで登場している'''再帰構成'''(recursive composition)が一つのキーワードである。[[再帰]]の概念は後続の文章にも再三登場しており、Smalltalk設計のあらゆる局面に影響を与えている。もっとも再帰はコンピュータプログラミング分野の普遍的概念であり、例えば[[ジョン・マッカーシー]]も[[LISP]]の設計を<code>recursive functions of symbolic expressions and their computation by machine.</code>''(記号式の再帰関数群と機械によるその計算)と概略していた。''{{Quotation|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.<br/>(Smalltalkは計算観念の自己再帰である。コンピュータプログラムをその全体からの劣化要素―データ構造、手続き、関数といった言語機能の諸々に分割していくのではなく、Smalltalkのオブジェクトはそれぞれが全体的な計算可能性を備えた再帰要素になる。)}}Smalltalkオブジェクトが備えている全体的な計算可能性とは実装レベルでは、一般的な関数呼び出しの代わりに、その関数名シンボルに相当するセレクタを実行時解釈する[[メッセージパッシング]]の仕組みを用いることと、セレクタの自由な解釈による他の関連オブジェクトへの積極的な[[委譲]]を用いることを意味している。その対義概念になる全体からの劣化要素への分割とは、いわゆる型付けによる[[型システム]]の導入と同義になり、他の論考でもケイは[[型システム]]に対して否定的な見解を示していた。[[型理論]]からの主旨がフォールトアヴォイダンスである[[型システム]]に対して、オブジェクト指向はフォールトトレランスが前提ということになる。ただし全体的な計算可能性を表現するための[[委譲]]は規則的かつ段階的に行われるべきであったので、そのために[[クラス (コンピュータ)|クラス]]と[[インスタンス]]の仕組みが実装された。{{Quotation|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. <br/>(哲学面でのSmalltalkオブジェクトは、[[ライプニッツ]]の[[モナド]]や20世紀の物理・生物学思考との共通点を見出せる。オブジェクトの構築は全くの[[プラトン|プラトニック]]であり、顕現の想起性を根底にした[[イデア論]]としてのものである。)}}


ここでの[[モナド (哲学)|モナド]]はオブジェクトの情報隠蔽を示唆しており、[[イデア論]]はクラスのインスタンス化を示唆している。クラスもまたメタクラスのインスタンス化であり、メタクラスもまたそのメタクラスのインスタンス化である。メタクラスの[[生命の樹 (旧約聖書)|木構造]]を[[イデア]]への上方に辿っていき適切なノードで別系統現象への下方に降りていくといった[[委譲]]サーチが全体的な計算可能性といった表現につながる。この委譲サーチをメッセージとするならば、この記事当時のメッセージは横つながりのネット的な連携よりも、縦つながりのヒエラルキー的な連携が主体であったことになる。実際にこのThe Early History Of Smalltalkにおいて[[ARPA]]は度々登場するが、[[ARPANET]]は一度も登場していない。
2, ''Objects communicate by sending and receiving messages (in terms of objects).


「インスタンス化」とは原型クラスの抽象内容を全て具体化して新たな抽象内容を付け足すという作業である。抽象内容が未付加ならばそこが末端インスタンスになる。それとは異なる「サブクラス化」とは原型クラスの抽象内容をそのままにして新たな抽象内容と具象内容を付け足すという作業である。これは[[継承 (プログラミング)|継承]]と呼ばれるが、Smalltalkは当初これを採用しなかった。[[継承 (プログラミング)|継承]]は後のオブジェクト指向で最も物議を醸した概念にもなっているのでその先見性が伺える。第四章では、Smalltalkをより汎化したような言語仕様が六つの要約にまとめられており、以下六項目には上述の再帰構成および自己再帰の計算性質が随所に盛り込まれている。{{Quotation|1, EverythingIsAnObject.
3, ''Objects have their own memory (in terms of objects).


2, Objects communicate by sending and receiving messages (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).
3, Objects have their own memory (in terms of objects).


4, Every object is an instance of a class (which must be an object).
6, ''To eval a program list, control is passed to the first object and the remainder is treated as its message.|Alan Kay}}''この和訳は以下のようになるが、ここでは長い説明を避けて特徴的な要点のみを解説する。''

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.}}この和訳は以下のようになるが、ここでは長い説明を避けて再帰構成にまつわる要点のみを解説する。


# すべてはオブジェクトである。
# すべてはオブジェクトである。
47行目: 56行目:
# プログラムリストの評価では、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。
# プログラムリストの評価では、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。


(3)のオブジェクトの記憶とはつまりデータであるが、変数名キーのマッピングによる一つの辞書データとして実装されて[[動的型付け]]性質になる。(4)は、クラスもまた[[メタクラス]]のインスタンスであり、メタクラスもまたメタメタクラスのインスタンスになるとを意味している。(5)は、振る舞いとはプレースホルダを内包しているプログラムリストであることを意味している。プレースホルダはインスタンス変数箇所であり実体化されたインスタンス別に変数内容が定まる。プログラムリストとは[[LISP]]のフォームリストに因んだものであり、関数変数シンボルとアトムと数値を連ねたデータ列で、これをコードとして解釈演算するのが評価(eval)である。(6)、振る舞いの評価をその保持元オブジェクトだけなく全く別のオブジェクトの制御下でも行えることを意味しており、これ振る舞い内容自体をも渡せる[[委譲]]を可能する。振る舞い=プログラムリスト内のシンボルは制御オブジェクトの記憶よって意味内容が変わので実行時多態と同義になる。
'''(2)'''コミュニケーションとは、オブジェクトの呼出ないし[[委譲]]による自己再帰、相互再帰、巡回再帰の流れを指していると見てよい。'''(3)'''の記憶とはつまりデータであるが、キーと値のマッピングによる辞書データとして実装されて[[動的型付け]]性質になり、値=オブジェクトなので即ちオブジェクトの記憶とはオブジェクトの再帰構成になる。'''(4)'''は、[[クラス (コンピュータ)|クラス]]もまた[[メタクラス]]の[[インスタンス]]であり、メタクラスもまたメタメタクラスのインスタンスになるという再帰構成を意味している。'''(5)'''の振る舞いとはプレースホルダを内包しているプログラムリストであることを意味している。プレースホルダは[[インスタンス変数]]箇所であり実体化されたインスタンス別に変数内容が定まる。プログラムリストとは[[LISP]]のフォームリストに因んだものであり、関数変数シンボルとアトムと数値を連ねたデータ列で、これをコードとして解釈演算するのが評価(eval)である。数値とアトム(文字列)はオブジェクトである。アトムとシンボルは表裏一体存在であり、双方は文脈によって自在に切り替わる。変数シンボルはただ評価されて束縛先オブジェクトになり、関数シンボル引数/空引数と共にプロ付帯評価されて返り値オブジェクになる。'''(6)'''は、シンボル・アトム・数値などその時の並べられた順序によっていずれもが制御オブジェクトにか、それに渡されるメッセージになるという再帰構成を意味している。

1998年に''上記のより長めの六つの要約が第三者を通して発表されている''<ref>{{Cite web|url=http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented|title=Alan Kays Definition Of Object Oriented|accessdate=2020-1|publisher=}}</ref>''。''これは[[Smalltalk]]から派生した[[Squeak]]の言語仕様を念頭に置いているようである。<blockquote>

1, EverythingIsAnObject.

2, Communication is performed by objects communicating with each other, requesting that objects perform actions. Objects communicate by sending and receiving messages. A message is a request for action, bundled with whatever objects may be necessary to complete the task.

3, Objects have their own memory, which consists of other objects.

4, Every object is an instance of a class. A class simply represents a grouping of similar objects, such as integers or lists.

5, The class is the repository for behavior associated with an object. That is, all objects that are instances of the same class can perform the same actions.

6, Classes are organized into a singly-rooted tree structure, called the inheritance hierarchy. Memory and behavior associated with instances of a class are available to any class associated with a descendent in this tree structure.</blockquote>''この和訳は冗長になるので割愛するが、概略するとオブジェクトに振る舞いを求めるメッセージにも他のオブジェクトが内包されており、またオブジェクトの記憶も他のオブジェクトのコンポジションであることが強調されている。''(6)が以前と異なっており、プログラムリスト評価の構想が、単一継承を重視する考えに置き換えられている。これはSqueakが部分的に[[クラスベース]]を採用したことを受けてのようで、無制限に動的な[[メッセージパッシング]]から、一部を静的にした動的ディスパッチへの方針転換を示しており、メッセージベースは実装上の限界を悟らされてやや形骸化したとも解釈できる。


=== 2000年代の言及 ===
=== 2000年代の言及 ===
21世紀になると[[Smalltalk]]処理系の開発は下火になったが、それ故に実装可能性の束縛から離れた元々の構想が語られる機会も生み出している。2003年にアラン・ケイはオブジェクト指向への貢献で[[チューリング賞]]を受賞し、知人から改めてオブジェクト指向の意味を尋ねられたケイは以下のようにメール返信している<ref>{{Cite web|url=http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en|title=Dr. Alan Kay on the Meaning of “Object-Oriented Programming”|accessdate=2019-1|publisher=}}</ref>。このメールは1960年代末からの源流構想をケイらしくさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋しながら説明していく。

21世紀になると[[Smalltalk]]処理系の開発は下火になったが、それ故に実装可能性の束縛から離れた元々の構想が語られる機会も生み出している。2003年にアラン・ケイはオブジェクト指向への貢献で[[チューリング賞]]を受賞し、知人から改めてオブジェクト指向の意味を尋ねられたケイは以下のようにメール返信している<ref>{{Cite web|url=http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en|title=Dr. Alan Kay on the Meaning of “Object-Oriented Programming”|accessdate=2019-1|publisher=}}</ref>。このメールは1960年代末からの源流構想をケイらしくさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋しながら説明していく。<blockquote>'''I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.'''(さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによってコミュニケーションする存在、僕はオブジェクトをそう考えている)</blockquote>
{{Quotation|I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.<br/>(さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによってコミュニケーションする存在、僕はオブジェクトをそう考えている)}}
上記はケイ本来のオブジェクトの在り方を述べたものであり、特に解説はしない。

{{Quotation|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, ...<br/>(僕はデータを取り除きたかった。これを[[バロース B5000|バロースB5000]]は驚くべきHWアーキテクチャでほとんど実現していた。僕は気付いた。細胞/全体コンピュータメタファはデータを除去できるであろうと、)}}
上記はケイ本来のオブジェクトの在り方を述べたものであり、特に解説はしない。<blockquote>
ここでプログラムからデータを取り除きたいという独特の考えが提示されている。なお、HWアーキテクチャとは前節での再帰構成の仕組みに似た技術のようである。細胞/全体(cell/whole)というワードもそれと同等と見てよい。
'''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|バロースB5000]]は信じがたい技術でほ実現していた。僕は気付いた。細胞/全体コンピュータメタファはデータを除去できるであろうと、)</blockquote>
{{Quotation|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.<br/>(僕の数学専攻経験がこれを気付かせた。各オブジェクトは幾つかの関連付けられた代数を持ち、またその系統群もあるかもしれない。それらは大変有用になるだろうと)}}
ここでプログラムからデータを取り除きたいという独特の考えが提示されている。<blockquote>
ここで代数というワードが登場する。これは数学で言われる[[代数的構造]]のプログラミング応用例と解釈してよい。
'''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.''' (僕の数学専攻経験がこれを気付かせた。各オブジェクトは幾つかの代数を持ち、またその系統群もあるかもしれない。それらは大変有用になるだろうと)</blockquote>
{{Quotation|OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.<br/>(僕にとってのOOPとは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった)}}
ここで代数というワードが登場する。これは数学で言われる[[代数的構造]]のプログラミング応用例と解釈してよい。<blockquote>
メッセージングは恐らく[[メッセージパッシング]]に類似の概念であるが、一般に連想されやすい[[リモートプロシージャコール]]とは異なることが言及されているので、そうした理由からこちらの造語が使われているようである。ステートプロセスは前節の再帰構成(recursive composition)と前述の代数(algebra)と後述の非データ(non-data)の考え方を合わせた独特のデータとコードの一体化概念であり、これも造語である。[[動的束縛|遅延バインディング]]は関数/変数の実行時多態である。
'''OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.'''(僕にとってのOOPとは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった)</blockquote>
メッセージングは[[メッセージパッシング]]に類似の概念であり、[[動的束縛|遅延バインディング]]は関数/変数の実行時多態である。ステートプロセスは前述の代数(algebra)と後述の非データ(non-data)の考え方を合わせた独特のデータとコードの一体化概念である。<blockquote>'''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を触媒にした二本の道があったという事だ。最初の一本はバイオ/ネットな非データ手順で僕が選んだ方。少し遅れたもう一本は抽象データ型でこっちの方がずっと賑わっている)</blockquote>ここで[[抽象データ型]](abstract data type)に対する非データ手順(non-data-procedure)というワードが登場する。振る舞いを通してデータを扱うというデータ抽象の概念を、更に抽象化したものが非データであり、[[代数学]]で言う[[写像]]のみによってデータを表現するという概念を指している。写像の組み合わせはメッセージングとの類似概念になり、あらゆるプログラム要素の遅延バインディングにも繋がる。その実装理論には[[圏論]]で言われる[[射 (圏論)|射]]や[[関手]]の構造が応用されることになり、関数型言語の世界ではそれで実践されている。<blockquote>'''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は[[ラムダ式]]を用いての手順によるデータ抽象化の正しい方法を書き示した)</blockquote>非データ手順(non-data-procedure)のプログラミング実践例としては、ポイントフリースタイルや自由[[モナド (プログラミング)|モナド]]などが挙げられる。いずれも数学の[[代数的構造]]のプログラム応用例であり、純然たる[[宣言型プログラミング|宣言型]]および純粋[[関数型プログラミング|関数型]]の分野になるが、これにケイの生物学専攻を背景にしたバイオ/ネット(bio/net)なる考えが加えられている点に留意する必要ある。[[プロセス代数]]は[[並行計算]]の実装理論として重視されており、メッセージングはこにも近い概念になっている。<blockquote>'''The people who liked objects as non-data were smaller in number,'''(非データとしてのオブジェクトを好む者は少なかった、)</blockquote>ここで歴史に戻る。1960年代になると[[ソフトウェア危機]]としても語られるプログラム規模拡大に対応するために、サブルーチンとデータをまとめた[[モジュール]]という機能が登場した。このモジュールを土台にして1967年に[[オルヨハン・ダール]]らは[[クラス (コンピュータ)|クラス]]という機能を備えた[[Simula|Simula67]]を開発し、1969年から[[エドガー・ダイクストラ]]は真珠のネックレスという概念を備えた[[構造化プログラミング]]を提唱した。1974年から[[IBM|IBM社]]中心の研究者たちが[[構造化分析設計技法|構造化設計]]と総称される技法を発表し、構造化プログラミングはこちらに取って代わられた。1972年からアラン・ケイはメッセージングという概念を備えたオブジェクト指向を誕生させている。オブジェクト指向は後に[[クラスベース|クラス・パラダイム]]にマウントされている。
{{Quotation|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.<br/>(僕が触れるべき一つは、Simulaを触媒にした二本の道があったという事だ。最初の一本はバイオ/ネットな非データ手順で僕が選んだ方。少し遅れたもう一本は抽象データ型でこっちの方がずっと賑わっている)}}
ここで[[抽象データ型]](abstract data type)に対する非データ手順(non-data-procedure)というワードが登場する。振る舞いを通してデータを扱うというデータ抽象の概念を、更に抽象化したものが非データであり、[[代数学]]で言う[[写像]]のみによってデータを表現するという概念を指している。写像の組み合わせはメッセージングとの類似概念になり、あらゆるプログラム要素の遅延バインディングにも繋がる。その実装理論には[[圏論]]で言われる[[射 (圏論)|射]]や[[関手]]の構造が応用されることになり、関数型言語の世界ではそれで実践されている。[[代数的構造]]の[[マグマ (数学)|マグマ]]は二項演算子で結ばれた各項を入れ子的に次々と二項化できる再帰構成である。マグマに[[結合律]]を加えた[[半群]]は[[並行計算]]向けの再帰構成を可能にする。半群に[[単位元]]を加えた[[モノイド]]は[[恒等写像|恒等射]]によって非データ手順向けの再帰構成を可能にする。
{{Quotation|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.<br/>([[ユタ大学|ユタ]]での専攻知識で僕が解決した最初期の問題はメソッドとオブジェクトのみを用いてのデータの消滅だった。1960年代末にBob Balzerはデータレス・プログラミングというものを書き示した。直後の1970年にJohn Reynoldsは[[ラムダ式]]を用いての手順によるデータ抽象化の正しい方法を書き示した)}}
非データ手順(non-data-procedure)のプログラミング実践例としては、ポイントフリースタイルや自由[[モナド (プログラミング)|モナド]]などが挙げられる。いずれも数学の[[代数的構造]]のプログラム応用例であり、純然たる[[宣言型プログラミング|宣言型]]および純粋[[関数型プログラミング|関数型]]の分野になるこれにケイの生物学専攻を背景にしたバイオ/ネット(bio/net)なる考えが加えられているが、これは前述の細胞/全体(cell/whole)と似たような再帰構成的な概念と見てよい。[[プロセス代数]]は[[並行計算]]の実装理論として重視されており、メッセージングはこの枠組みにも沿った概念になっている。
{{Quotation|The people who liked objects as non-data were smaller in number,<br/>(非データとしてのオブジェクトを好む者は少なかった、)}}
ここで歴史に戻る。1960年代になると[[ソフトウェア危機]]としても語られるプログラム規模拡大に対応するために、サブルーチンとデータをまとめた[[モジュール]]という機能が登場した。このモジュールを土台にして1967年に[[オルヨハン・ダール]]らは[[クラス (コンピュータ)|クラス]]という機能を備えた[[Simula|Simula67]]を開発し、1969年から[[エドガー・ダイクストラ]]は真珠のネックレスという概念を備えた[[構造化プログラミング]]を提唱した。1974年から[[IBM|IBM社]]中心の研究者たちが[[構造化分析設計技法|構造化設計]]と総称される技法を発表し、構造化プログラミングはこちらに取って代わられた。1972年からアラン・ケイはメッセージングという概念を備えたオブジェクト指向を誕生させている。オブジェクト指向は後に[[クラスベース|クラス・パラダイム]]にマウントされている。


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


Q&Aサイトの[[Quora]]で「66~67年のオブジェクト指向という造語を発したアラン・ケイに誰かが影響を与えていたのか?」という質問に対して本人がこう回答している。なお、rotationとは「一つのコンピュータはどこかのコンピュータができることをできる、相互通信によってあらゆる規模の計算可能性を表現できる」を意味している。{{Quotation|''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”.''<br>(60年代、配列より複雑なソフトウェア構成体はしばしばオブジェクトと呼ばれており、僕のスキームにあった手続き付きの構造体もそうだった。rotation構想の後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。)<br><br>
Q&Aサイトの[[Quora]]で「1966~67年のオブジェクト指向という造語を発したアラン・ケイに誰かが影響を与えていたのか?」という質問に対して本人がこう回答している。なお、rotationとは「一つのコンピュータはどこかのコンピュータができることをできる、相互通信によってあらゆる規模の計算可能性を表現できる」を意味しており、これも再帰構成の考え方を踏襲している。{{Quotation|''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”.''<br>(60年代、配列より複雑なソフトウェア構成体はしばしばオブジェクトと呼ばれており、僕のスキームにあった手続き付きの構造体もそうだった。rotation構想の後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。)<br>
''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?''<br>(愚かしいこのオブジェクトは僕の考えを表現するのにとても悪い言葉だった。不活性的でデータを過剰に意識させたからだ。Simulaはプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい?)
''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?''<br>(愚かしいこのオブジェクトは僕の考えを表現するのにとても悪い言葉だった。不活性的でデータを過剰に意識させたからだ。Simulaはプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい?)
}}
|Alan Kay}}
== 脚注 ==
== 脚注 ==
'''出典'''{{Reflist}}
'''出典'''{{Reflist}}

2021年6月22日 (火) 14:15時点における版

オブジェクト指向(オブジェクトしこう、: object-oriented)は、ソフトウェア開発コンピュータプログラミングのために用いられる考え方である。元々は特定のプログラミングパラダイムを説明するために考案された言葉だった。明確な用語としては1970年代に誕生し、1980年代前半に知名度を得て、考案者の手を離れた自由で曖昧な定義のまま発展を続けた後に、1990年代に入るとソフトウェア工学の様々な分野にも応用されるようになった。ソフトウェア開発における一つの標語のような扱い方もされている。

オブジェクト指向の来歴

Alan Kay

オブジェクト指向(object-oriented)という用語自体は、1972年から80年にかけてプログラミング言語「Smalltalk」を開発したゼロックス社パロアルト研究所の計算機科学者アラン・ケイが、その言語設計を説明する過程で誕生している[1]。本人の述懐によると、大学院時代のケイがプログラミング言語「Simula」に感化されて日夜プログラミング・アーキテクチャの思索に耽っていた1967年頃、今何をしているのかと尋ねてきた知人に対して「object-oriented programmingだよ」と咄嗟の造語で答えたのが原点であるという。このオブジェクト指向が知名度を得るようになったのは1981年頃からであり、当時の著名なマイコン専門誌BYTEによるSmalltalkの誌上紹介が契機になっている。オブジェクト指向の中でケイ自身はメッセージングという考え方を重視していたが、世間の技術的関心はクラスインスタンスの仕組みの方に集まり、オブジェクト指向の解釈はケイの考えとは異なる方向性で推移していった。クラスを初めて導入した言語はSimulaの1967年版だったので、こちらも後付けでオブジェクト指向の源流に位置付けられている[2]。Simulaに結び付けられたオブジェクト指向と、Smalltalkで提唱されたオブジェクト指向の性格は全く異なるものだったので、双方の解釈に数々の齟齬を生じさせている[3]。1983年に計算機科学者ビャーネ・ストロヴストルップがSimulaのオブジェクト指向をモデルにした言語「C++」を公開し、このC++が人気を博した事でオブジェクト指向は本来のSmalltalkではなく、後付けのSimulaスタイルの方で認識されるようになった。

1986年からACM(計算機協会)がOOPSLA(オブジェクト指向会議)を年度開催するようになり、オブジェクト指向はコンピュータサイエンスの一つのムーブメントになった。OOPSLA初期のチェアパーソンは、Smalltalkが生まれたゼロックス社パロアルト研究所のフェローが務めることが多かった。Smalltalkは正確にはプログラミング言語とGUI運用環境を合わせたフレームワークであり、ゼロックスAlto機上のOSまたはミドルウェアとして開発されていた。Smalltalkは70年代のアラン・ケイが構想していたダイナブックのためのGUI環境でもあった。ダイナブックはパーソナルコンピュータの原型に位置付けられているものである。ゼロックスAltoGUIを初めて汎用的にサポートしたコンピュータとOSであり、かのスティーブ・ジョブスを啓発してMacintoshのモデルになったことはよく知られている。こうした背景からオブジェクト指向は、上述のプログラミング云々よりも、GUI(グラフィカル・ユーザー・インターフェース)を始めにした当時の先進的なソフトウェアデザインソフトウェアアーキテクチャのための開拓的なモデル理論として受け止められる方が好まれた。データベース開発とオペレーティングシステム開発およびユーザーインターフェース設計が最初の活用対象になり、産業プログラミング界隈の主流であった構造化(Structured)分野に倣うようにして、オブジェクト指向設計(OOD)オブジェクト指向分析(OOA)オブジェクト指向モデリング(OOM)といった科目も立ち上げられた。それらの研究は形式手法の確立に繋げられて1991年にブーチメソッドオブジェクトモデル化技法、1992年にオブジェクト指向ソフトウェア工学が発表され、いずれも形式言語化されていたのでオブジェクトモデリング言語という総称用語を生み出した。上記三種の考案者(スリーアミーゴス)は、後のIBMブランドになるラショナルソフトウェアで合流して統一モデリング言語(UML)を構築するに到り、1995年のOOPSLAで初回発表した。デザインパターンリファクタリングモデル駆動工学ドメイン固有言語アジャイルソフトウェア開発といった数々のトピックもOOPSLAから誕生している。

1989年にはIBM社Appleヒューレットパッカード社サンマイクロシステムズ社アメリカン航空などの11社がコンピュータ産業共同事業団体OMG(Object Management Group)を設立した。OMGの目的は、企業システムネットワークの基盤になる分散コンピューティングを構築するための基礎要素になる分散オブジェクト設計の標準化を図ることであった。ここでのオブジェクトもデータとメソッド(=コード)の組み合わせと定義されていたので、この業務用システムおよびネットワークの構築を目的にした技術アーキテクチャもオブジェクト指向のカテゴリに入れられた。1991年に分散オブジェクトの規格パラダイムとなるCORBAが公開された。また1997年にOMGが標準モデリング言語として採用したUMLは、オブジェクト指向準拠のソフトウェア設計およびシステム設計のスタンダードに位置付けられた。

オブジェクト指向の分野

オブジェクト指向はプログラミングパラダイムとして誕生した理論である。そのデータ(変数またはプロパティ)とコード(関数またはメソッド)のセットを基本要素にして物事を解析する考え方が1980年代から大きく注目され始めたことで、ソフトウェア開発の様々な局面にobject-orientedを接頭辞にした分野が立ち上げられた。大まかな特徴としては情報資源と処理手順を区分けして分析と設計を行っていた従来の標準的な手法に対し、オブジェクト指向と名が付く分野ではこの双方をひとまとめにして処理対象の分析と設計を行う点が共通している。

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

1970年代にゼロックス社パロアルト研究所で誕生し、1981年頃から知名度を得るようになったオブジェクト指向(object-oriented)は同時に発案者であるアラン・ケイの手を離れてプログラミング思想から、スローガンを兼ねたソフトウェア工学理論へと認識拡大し、1986年以降はACM(計算機協会)開催のOOPSLA(オブジェクト指向会議)が中心的な担い手の役割を果たしていた。百家争鳴の様相を呈するようになったオブジェクト指向の世界に対して彼自身の言及は少なくなっている。

1980年代の言及

1989年に発表された「User Interface A Personal View」という記事の中でアラン・ケイは、Smalltalkのオブジェクト指向性は大変示唆的であると前置きした上で、そのプログラミング言語でのOOPと、そのGUIフレームワークでのOOUIを照応させながらこう述べている[4]。これは人とコンピュータの対話形式としてのオブジェクト指向に沿ったものになっている。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.
(双方の事例において私達は、オブジェクト(対象)を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する)

1990年代の言及

1992年にACMからプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌年の「The Early History Of Smalltalk」でオブジェクト指向の原点としてのSmalltalkについて解説している[1]。冒頭の序章で設計理念が説明され、第一章から第三章まではその着想元になったバロースB5000SketchpadSimula、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の設計―及び存在―とは、私たちの思い描く全てが、自身のステートとプロセスの連携を内包した個々の振る舞い組立ブロックの再帰構成によって表現され、徹底的なメッセージの交換のみによって処理されるということだ。)

ここで登場している再帰構成(recursive composition)が一つのキーワードである。再帰の概念は後続の文章にも再三登場しており、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のオブジェクトはそれぞれが全体的な計算可能性を備えた再帰要素になる。)

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世紀の物理・生物学思考との共通点を見出せる。オブジェクトの構築は全くのプラトニックであり、顕現の想起性を根底にしたイデア論としてのものである。)

ここでのモナドはオブジェクトの情報隠蔽を示唆しており、イデア論はクラスのインスタンス化を示唆している。クラスもまたメタクラスのインスタンス化であり、メタクラスもまたそのメタクラスのインスタンス化である。メタクラスの木構造イデアへの上方に辿っていき適切なノードで別系統現象への下方に降りていくといった委譲サーチが全体的な計算可能性といった表現につながる。この委譲サーチをメッセージとするならば、この記事当時のメッセージは横つながりのネット的な連携よりも、縦つながりのヒエラルキー的な連携が主体であったことになる。実際にこのThe Early History Of SmalltalkにおいてARPAは度々登場するが、ARPANETは一度も登場していない。

「インスタンス化」とは原型クラスの抽象内容を全て具体化して新たな抽象内容を付け足すという作業である。抽象内容が未付加ならばそこが末端インスタンスになる。それとは異なる「サブクラス化」とは原型クラスの抽象内容をそのままにして新たな抽象内容と具象内容を付け足すという作業である。これは継承と呼ばれるが、Smalltalkは当初これを採用しなかった。継承は後のオブジェクト指向で最も物議を醸した概念にもなっているのでその先見性が伺える。第四章では、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のフォームリストに因んだものであり、関数変数シンボルとアトムと数値を連ねたデータ列で、これをコードとして解釈演算するのが評価(eval)である。数値とアトム(文字列)はオブジェクトである。アトムとシンボルは表裏一体の存在であり、双方は文脈によって自在に切り替わる。変数シンボルはただ評価されて束縛先オブジェクトになり、関数シンボルは引数/空引数と共にプロセス付帯評価されて返り値オブジェクトになる。(6)は、シンボル・アトム・数値などはその時の並べられた順序によっていずれもが制御オブジェクトになるか、それに渡されるメッセージになるという再帰構成を意味している。

2000年代の言及

21世紀になるとSmalltalk処理系の開発は下火になったが、それ故に実装可能性の束縛から離れた元々の構想が語られる機会も生み出している。2003年にアラン・ケイはオブジェクト指向への貢献でチューリング賞を受賞し、知人から改めてオブジェクト指向の意味を尋ねられたケイは以下のようにメール返信している[5]。このメールは1960年代末からの源流構想をケイらしくさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋しながら説明していく。

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アーキテクチャでほとんど実現していた。僕は気付いた。細胞/全体コンピュータメタファはデータを除去できるであろうと、)

ここでプログラムからデータを取り除きたいという独特の考えが提示されている。なお、HWアーキテクチャとは前節での再帰構成の仕組みに似た技術のようである。細胞/全体(cell/whole)というワードもそれと同等と見てよい。

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とは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった)

メッセージングは恐らくメッセージパッシングに類似の概念であるが、一般に連想されやすいリモートプロシージャコールとは異なることが言及されているので、そうした理由からこちらの造語が使われているようである。ステートプロセスは前節の再帰構成(recursive composition)と前述の代数(algebra)と後述の非データ(non-data)の考え方を合わせた独特のデータとコードの一体化概念であり、これも造語である。遅延バインディングは関数/変数の実行時多態である。

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を触媒にした二本の道があったという事だ。最初の一本はバイオ/ネットな非データ手順で僕が選んだ方。少し遅れたもう一本は抽象データ型でこっちの方がずっと賑わっている)

ここで抽象データ型(abstract data type)に対する非データ手順(non-data-procedure)というワードが登場する。振る舞いを通してデータを扱うというデータ抽象の概念を、更に抽象化したものが非データであり、代数学で言う写像のみによってデータを表現するという概念を指している。写像の組み合わせはメッセージングとの類似概念になり、あらゆるプログラム要素の遅延バインディングにも繋がる。その実装理論には圏論で言われる関手の構造が応用されることになり、関数型言語の世界ではそれで実践されている。代数的構造マグマは二項演算子で結ばれた各項を入れ子的に次々と二項化できる再帰構成である。マグマに結合律を加えた半群並行計算向けの再帰構成を可能にする。半群に単位元を加えたモノイド恒等射によって非データ手順向けの再帰構成を可能にする。

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)のプログラミング実践例としては、ポイントフリースタイルや自由モナドなどが挙げられる。いずれも数学の代数的構造のプログラム応用例であり、純然たる宣言型および純粋関数型の分野になる。これにケイの生物学専攻を背景にしたバイオ/ネット(bio/net)なる考えが加えられているが、これは前述の細胞/全体(cell/whole)と似たような再帰構成的な概念と見てよい。プロセス代数並行計算の実装理論として重視されており、メッセージングはこの枠組みにも沿った概念になっている。

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

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

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

2020年の言及

Q&AサイトのQuoraで「1966~67年のオブジェクト指向という造語を発したアラン・ケイに誰かが影響を与えていたのか?」という質問に対して本人がこう回答している。なお、rotationとは「一つのコンピュータはどこかのコンピュータができることをできる、相互通信によってあらゆる規模の計算可能性を表現できる」を意味しており、これも再帰構成の考え方を踏襲している。

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年代、配列より複雑なソフトウェア構成体はしばしばオブジェクトと呼ばれており、僕のスキームにあった手続き付きの構造体もそうだった。rotation構想の後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。)

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はプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい?)

脚注

出典

関連項目

外部リンク