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

削除された内容 追加された内容
(同じ利用者による、間の3版が非表示)
20行目:
* [[オブジェクト指向分析設計]] - 1990年代から ←({{仮リンク|オブジェクト指向デザイン|en|Object-oriented design|label=オブジェクト指向設計}}、[[オブジェクト指向モデリング]])
* [[統一モデリング言語|UML]] - 1995年から ←([[Booch法|ブーチメソッド]]、[[オブジェクトモデル化技法]]、[[オブジェクト指向ソフトウェア工学]])
* {{仮リンク|オブジェクト指向マネージメント|en|Object-oriented Management|label=}} - 2000年代から
* {{仮リンク|オブジェクト指向存在論|en|Object-oriented ontology}} - 哲学分野
 
==アラン・ケイのオブジェクト指向とは==
1970年代に[[ゼロックス|ゼロックス社]][[パロアルト研究所]]で誕生し、1981年頃から知名度を得るようになったオブジェクト指向(''object-oriented'')は同時に発案者である[[アラン・ケイ]]の手を離れて[[プログラミングパラダイム|プログラミング思想]]から、スローガンを兼ねた[[ソフトウエア工学知識体系|ソフトウェア工学]]分野理論へと認識拡大し、1986年以降は[[Association for Computing Machinery|ACM]](計算機協会)開催の[[OOPSLA]](オブジェクト指向会議)が中心的な担い手の役割を果たしていた。70年代から80年代前半百家争鳴の様相を呈するようかけてのなったオブジェクト指向は[[Smalltalk]]言語仕様一環と世界に対してそれに当たることで一定彼自身理解を得られたが、80年代後半以降言及事情が異少なくなっている。
 
=== コンセプト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}}
1970年代に[[ゼロックス|ゼロックス社]][[パロアルト研究所]]で誕生し、1981年頃から知名度を得るようになったオブジェクト指向(''object-oriented'')は同時に発案者である[[アラン・ケイ]]の手を離れて[[プログラミングパラダイム]]から[[ソフトウエア工学知識体系|ソフトウェア工学]]分野へと認識拡大し、1986年以降は[[Association for Computing Machinery|ACM]](計算機協会)開催の[[OOPSLA]](オブジェクト指向会議)が中心的な担い手の役割を果たしていた。70年代から80年代前半にかけてのオブジェクト指向は[[Smalltalk]]言語仕様の一環としてそれに当たることで一定の理解を得られたが、80年代後半以降は事情が異なっている。
=== 1990年代の言及 ===
 
1992年に[[Association for Computing Machinery|ACM]]からプログラミング言語史編纂の一環として執筆を依頼された[[アラン・ケイ]]は、翌年のACM刊行記事においてオブジェクト指向の構想改めて六つの要約にまとめて説明した<ref name="EarlyHistoryOfSmalltalk" />。これは[[Smalltalk]]の言語仕様の概略であり、いわゆるメッセージベースのオブジェクト指向プログラミングの定義に沿ったものになっている。{{Quotation|1, ''EverythingIsAnObject.
==== 1989年頃 ====
1989年に発表されたUser Interface A Personal Viewという記事の中でアラン・ケイは、Smalltalkのオブジェクト指向性は大変示唆的であると前置きした上でこう述べている<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}}これは[[認知心理学]]の[[アフォーダンス]]につながる考え方と解釈されている。この意味についてケイは抽象的なシンボルの視点と、具象的なユーザーインターフェース表示の視点のプロセスを対照させながら説明している。前者では我々はまずオブジェクトの名前(識別子)を示し、次にそのオブジェクトが実行する”なにか”を知らせるメッセージを続かせることになる。メッセージには実コードや実データの中間参照になる抽象的シンボル(文字列ないし数列)が含まれている。後者では我々はまず操作する対象を選択し、次にその対象が提供する”なにか”のメニュー覧を表示させることになる。メニューの各項目名は抽象的シンボルと同義になる。この双方を踏まえた上でケイはこう結論している。{{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}}
==== 1993年頃 ====
1992年に[[Association for Computing Machinery|ACM]]からプログラミング言語史編纂の一環として執筆を依頼された[[アラン・ケイ]]は、翌年のACM刊行記事においてオブジェクト指向の構想を改めて六つの要約にまとめて説明した<ref name="EarlyHistoryOfSmalltalk" />。{{Quotation|1, ''EverythingIsAnObject.
 
2, ''Objects communicate by sending and receiving messages (in terms of objects).
41 ⟶ 38行目:
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.|Alan Kay}}''この和訳は以下のようになるが、ここでは長い説明を避けて特徴的な要点のみを解説する。''
 
# すべてはオブジェクトである。
# オブジェクトはメッセージの送信と受信によってコミュニケーションする。
# オブジェクトは自身の記憶を持つ。
# すべてのオブジェクトはクラスのインスタンスである。クラスもまたオブジェクトであるべきである。
# クラスはそのインスタンスたちのために共有される振る舞いを保持する。振る舞いはプログラムリストオブジェクトの形態である。
# プログラムリストの評価では、制御は最初のオブジェクトに渡され、残りはそのメッセージとして処理さ扱われる。
 
(3)のオブジェクトがhaveする記憶とはつまりデータであるがオブジェクト所属変数名キーのマッピングによる一つ辞書データとして実装されて[[動的型付け]]性質になる。(4)は、クラスもまた[[メタクラス]]ようインスタンスである。オブジェり、メタトがholdすラスもまたメタメタクラスのインスタンスになことを意味している。(5)は、振る舞いと形容されはプレースホルダを内包しているプログラムリストであるこを意味している。プレースホルダインスタンス変数箇所であり実体化されたインスタンス別に変数内容が定まる。プログラムリストとは[[LISP]]のフォームないしフォームリストに因んだものであり、関数シンボル、変数シンボルアトム数値といったものを連ねたデータ列である。のデータ列をコードとして解釈演算するのが評価(eval)である。(6)は、振る舞いの評価をその保持元オブジェクトだけでなく全く別のオブジェクトの制御(control)す下でも行え権利はメッセージの受け取ことを意味してお側に渡さ、こは振舞い内容自体をも渡せる[[委譲]]を可能にする。振る舞い=プログラムリスト内で、同じシンボルでもそのは制御オブジェクトの文脈(context)記憶によって意味内容が変わるというので実行時多態を表わしていと同義になる。
 
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>
==== 1998年頃 ====
1998年にAn Introduction To Object-Oriented Programming''を出版した[[オレゴン大学]]コンピュータサイエンス教授ティム・バッドによると、この時期のアラン・ケイの構想はこのようになっていた''<ref>{{Cite web|url=http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented|title=Alan Kays Definition Of Object Oriented|accessdate=2020-1|publisher=}}</ref>''。''{{Quotation|1, ''EverythingIsAnObject.
 
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.
 
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.
 
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.
 
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.
 
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.|Alan Kay}}この和訳は以下のようになる。''
 
# すべてはオブジェクトである。
# コミュニケーションはオブジェクトに動作実効を要求するオブジェクトの相互通信で実効される。オブジェクトはメッセージの送受信でコミュニケーションする。メッセージはタスク遂行に必要なオブジェクトが付帯された動作要求である。
# オブジェクトは自身の記憶を持つ。記憶は他のオブジェクトたちで構成されている。
# すべてのオブジェクトはクラスのインスタンスである。クラスは数値集合やリスト集合といったように類似オブジェクトのグループ化をシンプルに表現する。
# クラスはオブジェクトに関連付けられた振る舞いのリポジトリである。同じクラスのインスタンスである全てのオブジェクトは共通動作を実効できる。
# クラスは継承階層と呼ばれる単一ツリー構造で組成される。クラスのインスタンスの記憶と振る舞いは、ツリー構造下の子孫であるクラスからも利用できる。
 
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が部分的に[[クラスベース]]を採用したことを受けてのようで、無制限に動的な[[メッセージパッシング]]から、一部を静的にした動的ディスパッチへの方針転換を示しており、メッセージベースは実装上の限界を悟らされてやや形骸化したとも解釈できる。
 
==== 20032000代の言及 ====
 
2003年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>。{{Quotation|このメールは1960年代末からの源流構想をケイらしくさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋しながら説明していく。<blockquote>''OOP'I tothought meof meansobjects onlybeing messaging,like localbiological retentioncells and/or protectionindividual andcomputers hidingon ofa state-processnetwork, andonly extremeable late-bindingto ofcommunicate allwith thingsmessages.'''(さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによってコミュニケーションする存在、僕はオブジェクトをそう考えている)</blockquote>
<br>(僕にとってのオブジェクト指向とは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった。)|Alan Kay}}
 
上記はケイ本来のオブジェクトの在り方を述べたものであり、特に解説はしない。<blockquote>
「''messaging''」「''state-process''」「''late-binding''」のうち一番目と二番目は、''object-oriented''と同様にケイの造語のようである。一番目はオブジェクト同士のコミュニケーションを指しており[[メッセージパッシング]]に類似の概念である。二番目のステートプロセスは状態処理が適訳と思われるが、元々が造語であるため詳細は漠然としている。
'''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>
ここでプログラムからデータを取り除きたいという独特の考えが提示されている。<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>
ここで代数というワードが登場する。これは数学で言われる[[代数的構造]]のプログラミング応用例と解釈してよい。<blockquote>
<br>'''OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.'''(僕にとってのオブジェクト指向OOPとは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった|Alan Kay}}</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年からアラン・ケイはメッセージングという概念を備えたオブジェクト指向を誕生させている。オブジェクト指向は後に[[クラスベース|クラス・パラダイム]]にマウントされている。
 
[[構造化プログラミング|構造化設計]]はモジュールをそのままサブルーチンとデータの構成体として扱っている具象データ(concrete data)技術である。Simula発のクラスとダイクストラの真珠のネックレスは、モジュールに[[カプセル化]]・[[継承 (プログラミング)|継承]]・[[多態性]]を備えて抽象体として扱おうとする抽象データ(abstract data)技術である。そしてアラン・ケイ本来のオブジェクトとは、モジュールを[[生物学]]と[[代数学]]の観点から再解釈した非データ(non data)技術であった。構造化設計は1980年代までの主流であり、続けてオブジェクト指向が主流になったが、現在においてもクラスをただのデータとメソッドの構成体として扱っているようなオブジェクト指向は、構造化設計と大差ないものになり「具象データ」から「抽象データ」への思考転換の難しさを物語っている。モジュールの抽象化が提唱され始めたのは1970年代であったが、同時期にアラン・ケイは「抽象データ」を更に抽象化した「非データ」を構想していた。
==== 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構想の後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。)|Alan Kay}}
{{Quotation|''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}}
 
=== 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>
{{Quotation|''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}}
102 ⟶ 95行目:
*[[仮想マシン]]
*[[アクターモデル]]
*[[オブジェクト関係マッピング]]
 
==外部リンク==