コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
編集の要約なし
m 冒頭
 
(24人の利用者による、間の80版が非表示)
1行目: 1行目:
{{独自研究|date=2019年2月}}
{{複数の問題
'''オブジェクト指向'''(オブジェクトしこう、{{lang-en-short|''object-oriented''}})は、[[ソフトウェア開発]]と[[コンピュータプログラミング]]のために用いられる考え方である。元々は特定の[[プログラミングパラダイム]]を説明するために考案された言葉であり、その当時の革新的技術であったGUI([[グラフィカル・ユーザー・インターフェース|グラフィカル・ユーザーインターフェース]])とも密接に関連していた。明確な用語としては1970年代に誕生し、1981年頃から知名度を得て、1986年頃からソフトウェア開発のムーブメントと化した後に、1990年頃にはソフトウェア開発の総合技術としての共通認識を確立している。ソフトウェア開発における一つの標語のような扱い方もされている。
|独自研究=2019年2月
|正確性=2019年2月
|出典の明記=2019年2月
}}
'''オブジェクト指向'''(オブジェクトしこう、{{lang-en-short|''object-oriented''}})は、[[ソフトウェア工学]]理論の一つであり、ソフトウェア設計とプログラム記述の際に用いられる考え方である。元々は特定の[[プログラミングパラダイム|プログラミング・パラダイム]]を説明する為に考案された言葉だった。''object-oriented programming''のように修飾語として用いられるのが常であり、それ単体で扱われる事はない漠然とした設計構想でもある。{{main|オブジェクト指向プログラミング}}


オブジェクトとは、プログラミング視点では[[データ構造]]とその専属[[プロシージャ|手続き]]を一つにまとめたものを指しており、分析/設計視点では情報資源とその処理手順を一つにまとめたものを指している。[[データ]]と[[プロセス]]を個別に扱わずに、双方を一体化した[[オブジェクト (プログラミング)|オブジェクト]]を基礎要素にし、[[メッセージ (コンピュータ)|メッセージ]]と形容されるオブジェクト間の相互作用を重視して、ソフトウェア全体を構築しようとする考え方がオブジェクト指向である。{{main|オブジェクト指向プログラミング}}
== オブジェクト指向の成り立ち ==
オブジェクト指向(''object-oriented'')という言葉自体は、1972年から80年にかけてプログラミング言語「[[Smalltalk]]」を公開した計算機科学者[[アラン・ケイ]]が、その言語設計を説明する中で初めて生み出されている<ref name="EarlyHistoryOfSmalltalk">{{Cite web|url=http://worrydream.com/EarlyHistoryOfSmalltalk/|title=The Early History Of Smalltalk|author=Alan C. Kay|accessdate=2019-02-21}}</ref>。そこから遡って1967年に公開されていた「[[Simula|Simula 67]]」の[[クラス (コンピュータ)|クラス]]と[[オブジェクト (プログラミング)|オブジェクト]]の設計もオブジェクト指向の発端と見なされるようになった<ref>[http://kristennygaard.org/FORSKNINGSDOK_MAPPE/F_OO_start.html How Object-Oriented Programming Started]</ref>。データとコードの複合体であるオブジェクト(''object'')という用語を確立したのは[[Simula|Simula 67]]であったが<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|author=Jonathan Aldrich and Charlie Garrod|date=2014|accessdate=2019-02-02}}</ref>、その設計は[[手続き型プログラミング]]の機能拡張に近いものである。アラン・ケイ自身は「[[LISP]]」の影響を受けた事を強調しており<ref name="EarlyHistoryOfSmalltalk" />、実際に[[クラス (コンピュータ)|クラス]]の仕組みを除いた[[Smalltalk]]のオブジェクト指向設計は完全に別物であった。1958年に公開されていた[[LISP]]は[[マサチューセッツ工科大学|MIT]]の[[人工知能]](AI)研究と深い関わりを持っていた。その後、計算機科学者[[ビャーネ・ストロヴストルップ]]が1983年に公開した「[[C++]]」が契機となって、オブジェクト指向に関連する様々な考え方が再定義されている。[[C++]]の設計は[[Simula|Simula 67]]の方をモデルにしていた。


== オブジェクト指向の来歴 ==
上述の様にオブジェクト指向とは元々プログラミング・パラダイムとして編み出された理論であったが、1980年代から[[データベース]]と[[オペレーティングシステム|OS]]の開発にもその設計構想が活かされるようになり、1990年代になるとソフトウェア工学の幅広い面にも応用されて、オブジェクト指向を土台にした様々な分野が開拓される事になった。
[[ファイル:Alan Kay (3097597186) (cropped).jpg|サムネイル|222x222ピクセル|アラン・ケイ]]


==オブジェクト指向の分野==
=== オブジェクト指向プログラミング発案 ===
オブジェクト指向(''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で提唱されたオブジェクト指向の性格は全く異なるものだったので、後のオブジェクト指向の解釈に数々の齟齬を生じさせている。1983年に計算機科学者[[ビャーネ・ストロヴストルップ]]がSimulaをモデルにした言語「[[C++]]」を公開し、このC++が人気を博した事や、Smalltalkでも実際の開発に対応するためにSimulaスタイルの継承などの機能が取り入れられたことで、[[オブジェクト指向プログラミング]]はSimulaスタイルの方で認識されるようになった<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>。


* [[オブジェクト指向プログラミング]] (1970年代から)
=== オブジェクト指向開発の始動 ===
1986年から[[Association for Computing Machinery|ACM]](計算機協会)が[[OOPSLA]](オブジェクト指向会議)を年度開催するようになり、オブジェクト指向は[[コンピュータサイエンス]]の一つのムーブメントになった。[[OOPSLA]]初期のチェアパーソンは、[[Smalltalk]]が生まれた[[ゼロックス|ゼロックス社]][[パロアルト研究所]]のフェローが務めることが多かった。Smalltalkは正確には[[プログラミング言語]]と[[グラフィカルユーザインタフェース|GUI]][[ソフトウェアフレームワーク|フレームワーク]]を合わせた統合開発運用環境であり、[[Alto|ゼロックスAlto]]機上の[[オペレーティングシステム|OS]]または[[ミドルウェア]]として制作されていた。[[Alto|ゼロックスAlto]]は[[GUI]]を初めて汎用的にサポートしたコンピュータと[[オペレーティングシステム|OS]]であり、かの[[スティーブ・ジョブズ|スティーブ・ジョブス]]を啓発して[[Macintosh]]のモデルになったことはよく知られている。1980年代前半のコンピュータ界隈は、[[キャラクタユーザインタフェース|CUI]](キャラクタ・ユーザーインターフェース)から[[グラフィカルユーザインタフェース|GUI]](グラフィカル・ユーザーインターフェース)への過渡期であったので、すでに[[プログラミングパラダイム]]とGUIデザイン理論をミックスさせていたオブジェクト指向は、その当時における次世代的なソフトウェア開発技術になり得るものとして関心を集めていた。
* [[オブジェクトデータベース]] (1980年代から)
* [[オブジェクト指向分析設計]] (1990年代から)
* [[オブジェクト指向モデリング]] (1990年代から)


また別の背景としては、1970年代からの主流である[[構造化プログラミング|構造化開発]]が拡張を続けていた中で、様々な[[データ構造図]]や[[データフロー図]]の技法および[[データモデリング]]の手法がやや乱立気味になっていたという事情があり、その見直しを兼ねて一からの仕切り直しによるソフトウェア開発技術の標準化(standardization)を図りたいとする産業界や計算機科学界の思惑もあった。オブジェクト指向はそのためのスローガンとしても最適であった。こうした経緯から技術的以外の意味も与えられたオブジェクト指向は同時に[[バズワード]]化することにもなっている。[[構造化分析設計技法|構造化開発]]が[[機能モデル|機能]]を中心にして[[機能モデル|機能]]と[[データモデル|データ構造]]を個別にデザインする[[段階的詳細化法|段階的詳細化]]を基礎にしていたのに対し、オブジェクト指向はデータと機能を一つにまとめた[[オブジェクト (プログラミング)|object]]をソフトウェアデザインの中心にした上で[[エドガー・ダイクストラ]]発案の[[構造化プログラミング|抽象データ構造]]及び[[バーバラ・リスコフ]]提唱の[[抽象データ型]]を基礎にしていた。これは前述の[[Simula]]スタイル由来である。オブジェクト指向開発(object-oriented development)という言葉を最初に引用したのは、1986年のソフトウェア技術者[[グラディ・ブーチ]]であったとされる。その最初の活用対象になったのは、[[データベース]]開発と[[オペレーティングシステム]]開発および[[ユーザーインターフェース]]設計であった。
オブジェクト指向は、プログラミング・パラダイムとして誕生した知識体系である。そのデータ(変数またはプロパティ)とコード(関数またはメソッド)のセットを基本要素にして物事を解析する考え方が、1980年代から大きく注目され始めた事で、ソフトウェア工学のあらゆる局面に''object-oriented''を接頭辞にした分野が立ち上げられた。大まかな特徴としては、情報資源と処理手順を別々にして分析ないし設計を行っていた従来の標準的な手法に対し、オブジェクト指向と名が付く分野ではこの双方をひとまとめにして物事の解析と組み立てを行う点が共通している。


=== オブジェクト指向方法論の進展 ===
他にも、オブジェクト指向オペレーティングシステム、[[オブジェクト関係データベース]]、[[オブジェクト関係マッピング]]、[[オブジェクト指向ソフトウェア工学]]、オブジェクト指向ユーザーインターフェース、オブジェクト指向プロジェクト管理、[[Booch法|ブーチメソッド]]、[[オブジェクトモデル化技法]]など数々の分野が存在するが、上記リストの四種と知識範囲が重なり合っているか、または内包される副次分野となっていることから、一つの分野として特筆される事は少ない。
[[OOPSLA]]の開催と連動してまず[[オブジェクト指向設計]](OOD)と[[オブジェクト指向分析設計|オブジェクト指向分析]](OOA)が立ち上げられた。これは[[構造化プログラミング|構造化開発]]のSDとSAに倣っていた。1980年代後半からOOPSLA界隈の識者たちによって様々な分析メソッドと設計メソッドが発表されるようになった。この分析/設計メソッドから導出される[[コンセプトモデル|概念モデル]]を、形式的にチャート化ないし[[ダイアグラム|ダイアグラム化]]するという作業がモデリングであり、[[構造化分析設計技法|構造化開発]]でも[[機能モデル]]や[[データモデル]]や[[実体関連モデル]](ER図)などが存在していたが、抽象化を尊ぶオブジェクト指向開発では特にこのモデリングが重視されたのが特徴である。1988年のオブジェクト指向システム分析(OOSA)、1990年からの[[ピーター・コード|Coad]]&[[エドワード・ヨードン|Yourdon]]法、1991年の[[Booch法]]と[[オブジェクトモデル化技法]](OMT)、1992年の[[オブジェクト指向ソフトウェア工学]](OOSE)、1993年のフュージョンメソッドとMartin&Odell法といった数々のオブジェクト指向方法論(object-oriented methodology)による[[オブジェクト指向モデリング|モデリング手法]]が発表され、いずれも[[形式言語]]化されていたのでオブジェクト指向では、[[モデリング言語]]と[[プログラミング言語]]が並んでソフトウェア開発の両輪になった。


1990年前後から認知されるようになったオブジェクト指向方法論とは、[[オブジェクト指向分析設計|要求分析]]・[[オブジェクト指向設計|概念設計]]・[[オブジェクト指向モデリング|モデリング]]・[[オブジェクト指向プログラミング|プログラミング]]といった一連の工程を総括的に形式化した理論体系であり、ソフトウェア開発の総合技術としてのオブジェクト指向を体現していた。1994年にモデリング言語をプログラム設計に直接適用した[[ギャング・オブ・フォー (情報工学)|GOF]][[デザインパターン (ソフトウェア)|デザインパターン]]が初回発表された。Booch法とOMTとOOSEの考案者([[スリーアミーゴス]])は、後の[[IBM]]ブランドになる[[ラショナル|ラショナルソフトウェア]]で合流して[[統一モデリング言語]](UML)を制作し、1995年のOOPSLAで初回発表した。オブジェクト指向は[[ソフトウェア開発工程]]の分野にも広がり、[[モデル駆動工学]]、[[ドメイン固有言語]]、[[リファクタリング (プログラミング)|リファクタリング]]、[[アジャイルソフトウェア開発]]といった数々のトピックも[[OOPSLA]]から誕生している。[[ラショナル|IBMラショナル]]はオブジェクト指向開発工程フレームワークを標榜する[[ラショナル統一プロセス]]を2003年に公開した。
==オブジェクト指向とは==


1989年には[[IBM|IBM社]]、[[Apple]]社、[[ヒューレット・パッカード|ヒューレットパッカード社]]、[[サンマイクロシステムズ|サンマイクロシステムズ社]]、[[アメリカン航空]]などの11社がコンピュータ産業共同事業団体[[Object Management Group|OMG]](Object Management Group)を設立した。その主な目的は、企業システムネットワークの基盤になる[[分散コンピューティング]]を構築するための分散オブジェクト設計の標準化を図ることであった。ここでのオブジェクトもデータとメソッドの複合体と定義されていた。1991年に分散オブジェクトの規格パラダイムとなる[[CORBA]]が発表された。1997年に[[Object Management Group|OMG]]の標準モデリング言語は[[統一モデリング言語|UML]]に策定された。モデリングの[[形式体系]]化に力を注いでいたOMGは[[モデル駆動工学]]のメソッド確立を進めて、2001年に[[モデル駆動型アーキテクチャ|モデル駆動アーキテクチャ]]を発表している。
=== 概要 ===
オブジェクト指向(''object-oriented'')の言葉を生み出した計算機科学者[[アラン・ケイ]]は、1970年代に発表した文書の中でその設計構想を六つの要約で説明している<ref name="EarlyHistoryOfSmalltalk" />。


==オブジェクト指向の種類==
#''EverythingIsAnObject.''
* [[オブジェクト指向プログラミング]] - 1970年代から
#''Objects communicate by sending and receiving messages (in terms of objects).''
* [[オブジェクトデータベース]] - 1980年代から
#''Objects have their own memory (in terms of objects).''
**[[オブジェクト関係データベース]] - 1990年代から
#''Every object is an instance of a class (which must be an object).''
* {{仮リンク|オブジェクト指向オペレーティングシステム|en|Object-oriented operating system|label=}} - 1980年代から
#''The class holds the shared behavior for its instances (in the form of objects in a program list).''
* {{仮リンク|オブジェクト指向ユーザーインターフェース|en|Object-oriented user interface|label=}} - 1980年代から
#''To eval a program list, control is passed to the first object and the remainder is treated as its message.''
**オブジェクト指向ユーザーエクスペリエンス - 2010年代から
*[[オブジェクト指向分析設計|オブジェクト指向設計]] - 1980年代から
*[[オブジェクト指向分析設計|オブジェクト指向分析]] - 1980年代から
*[[オブジェクト指向モデリング]] - 1980年代から
*オブジェクト指向方法論 - 1990年代から
**Meyer法(オブジェクト指向ソフトウェア構築 - OOSC)
**Shlaer and Mellor法(オブジェクト指向システム分析 - OOSA)
**Wirfs-Brock法(責任駆動設計 - RDD)
**Coad and Yourdon法
**[[Booch法]]
**[[オブジェクトモデル化技法]](OMT)
**[[オブジェクト指向ソフトウェア工学]](OOSE)
**Gibson and Goldberg法(オブジェクト動作分析 - OBA)
**フュージョンメソッド ← Booch法・RDD・OMT・OOSE
**Martin and Odell法
**Graham法(意味論オブジェクトモデル化導入論 - SOMA)
**Henderson-Sellers法(オブジェクト指向システムソフトウェア工学方法論 - MOSES)
**[[統一モデリング言語]](UML)← Booch法・OMT・OOSE
**Openモデリング言語(OML)← フュージョンメソッド・SOMA・MOSES
**オブジェクト工学プロセス(OEP)← UML・OMT・OOSE
**[[ラショナル統一プロセス]](RUP)← UML・OMT・OOSE
* {{仮リンク|オブジェクト指向存在論|en|Object-oriented ontology}} - 哲学分野

==アラン・ケイのオブジェクト指向とは==
=== 1980年代の言及 ===
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/>(双方の事例において私達は、オブジェクト(対象)を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する)}}80年代前半までのオブジェクト指向はプログラミングとGUIの融合思想と言った方が適当であり、オペレータがプログラミングでカスタマイズした結果をGUIビュー環境でほぼ同時に確認できるという特性は、コマンドライン実行とキャラクタ文字環境が当然であった時代において革新的であった。プログラミングはコンピュータとの潜在的な対話であり、GUIは顕在的な対話であると形容されている。長じてアイコン選択とメニュー処理を適宜に連携させるGUIの考え方をプログラミングにも応用したものが、後述のオブジェクトとメッセージ式になっている。

=== 1990年代の言及 ===
1992年に[[Association for Computing Machinery|ACM]]からプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌93年の「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の設計―及び存在―とは、私たちの思い描ける全てが、自己の状態とプロセスの結合を内部隠蔽した個々の振る舞い組立ブロックの再帰構成によって表現され、徹底的なメッセージの交換のみによって処理されるということだ。)}}再帰構成すなわち[[再帰]]の概念は、後続文にも繰り返し登場している。もっとも再帰は一般知識であり、例えば[[ジョン・マッカーシー]]も[[LISP]]の設計を<code>recursive functions of symbolic expressions and their computation by machine.</code>(記号式の再帰関数群と機械によるその計算)と概略していた。メッセージ交換は、徹底的な[[疎結合]]および{{仮リンク|情報隠蔽|en|Information hiding|redirect=1}}を示唆している。{{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のオブジェクトはそれぞれが計算の総体可能性を備えた再帰要素になる。)}}ケイが理想とする計算の総体可能性の反対である劣化要素への分割とは、いわゆる[[型システム]]の導入を指している。他の論考でもケイは特に静的な[[型システム]]に対して否定的な見解を示していた。{{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世紀の物理・生物学思考との共通点を見出せる。オブジェクトの構築は、[[イデア論|イデア]]から現象が創生されるという全くの[[プラトン|プラトニック]]である。)}}

第四章では、Smalltalkの言語仕様が六つに概略されている。{{Quotation|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.}}この和訳は以下のようになるが、ここでは長い説明を避けて特徴的な要点のみを解説する。


これをやや意訳するとこうなる。
# すべてはオブジェクトである。
# すべてはオブジェクトである。
# オブジェクトはメッセージの送受信によって相互作用する。
# オブジェクトはメッセージの送信と受信によってコミュニケーションする。
# オブジェクトは自身の記憶領域(データ)を持つ。
# オブジェクトは自身の記憶を持つ。
# のオブジェクトクラスのインスタンスであり、クラスもまたオブジェクトである。
# すべてのオブジェクトクラスのインスタンスである。クラスもまたオブジェクトである。
# クラスはそのインスタンスの為の共有動作(メソッド)を持インスタンスはプログラムにおけるオブジェクトの形態である。
# クラスはそのインスタンス共有される振る舞いする振る舞いとはプログラムリスト・オブジェクトである。
# プログラム実行時は、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。
# プログラムリストの評価では、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。


'''(2)'''は様々に解釈されるが、コミュニケーションする[[オブジェクト (プログラミング)|オブジェクト]]は、[[プロセス計算|プロセス]]や[[アクターモデル|アクター]]としての性格が強くなる。'''(3)'''の記憶は簡単に言うと[[フィールド (計算機科学)|フィールド]]や[[プロパティ (プログラミング)|プロパティ]]や[[属性 (コンピューティング)|属性]]であるが、オブジェクトの振る舞いを制約するための私的環境を示唆している。'''(4)'''は、[[クラス (コンピュータ)|クラス]]もまた[[メタクラス]]の[[インスタンス]]化であるという再帰構成を示唆している。'''(5)'''の振る舞いは簡単に言うと[[メソッド (計算機科学)|メソッド]]であるが、[[LISP]]のフォームリストに似たオブジェクトとして保持されることを示唆している。'''(6)'''は、[[式 (プログラミング)|式]]内のオブジェクトはその時の並べられた順序によって、いずれもがコントローラ(関数式)になり、いずれもがそれへのメッセージ(引数)になることを示唆している。
'''(1)'''はプログラム内のあらゆる要素をオブジェクトとして扱う事を示している。従来の変数や文字列や構造体だけに留まらず、数値(プリミティブ)や真偽値(ブーリアン)や演算子(オペレータ)、更には手続き(コードブロック)や制御文(コントロールフロー)やクラス構造情報(メタデータ)までもオブジェクトにした点が一線を画していた。これがオブジェクト指向と名付けられた由縁である。


=== 2000年代の言及 ===
'''(2)'''のメッセージ送受信とは元々は、[[LISP]]が採用していた[[高階関数]]の仕組みを[[参照透過性]]と相反する観点から独自に拡張させたものであり、この視点の下では変換式に独自の記憶を持たせたものがオブジェクトとなった。オブジェクトを[[第一級関数]]と同様に入力値にも出力値にも出来る事がメッセージングに必須の枠組みである。オブジェクト指向の下では数式もメッセージングとなった。「3+5」は3というオブジェクトに+と5というメッセージが送られて8の結果値が返るといった具合である。+の演算子と5の引数値もオブジェクトであり、8の結果値もオブジェクトなので、それにまたメッセージを送る事も出来た。コードブロックもまたオブジェクトであり同時にメッセージにも出来たので、比較式オブジェクトが返す真偽値に対して特殊な予約語オブジェクトとコードブロックを併せて送る事で条件分岐や反復といった制御構文を表現する事も出来た。数値に対してコードブロックを送ると回数反復となった。オブジェクトを次々と引き合わせる(''communication'')のは順次処理となった。従来のプログラムリストで広く使われていた[[フローチャート]]が別の視点から眺められて、その図表上にある数値や記号や変数および順次や分岐や反復のフローといったあらゆる要素がオブジェクトとして分解され、オブジェクトにオブジェクトを引き合わせて双方に関連した処理を行わせるという全く新しいフローがメッセージと名付けられた。
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>。このメールは60年代末からの構想をさり気なく簡潔にまとめたものとしてしばしば引用される。ここでは文章順に各要点を抜粋していく。
{{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アーキテクチャでほとんど実現していた。僕は気付いた。細胞/全体コンピュータメタファはデータを除去できるであろうと、)}}
ここでプログラムからデータを取り除きたいという考えが提示されている。
{{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/>(僕の数学専攻経験がこれを気付かせた。各オブジェクトは幾つかの関連付けられた代数を持ち、またその系統群もあるかもしれない。それらは大変有用になるだろうと)}}
ここでの代数は、[[プロセス代数]]か、プログラミングに適用した[[代数的構造]]とも解釈できる。
{{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とは、メッセージング、ステートプロセスの局所保持かつ保護かつ隠蔽、徹底的な遅延バインディング、これだけの意味だった)}}
メッセージングは造語に近く、[[メッセージパッシング]]に類似の概念であり、ただの[[リモートプロシージャコール]]とは異なることが明言されている。ステートプロセスは、データとコードの一元化概念であり、これも造語である。[[動的束縛|遅延バインディング]]は、シンボルと実体の結合をランタイムで決定する概念である。
{{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を触媒にした二本の道があったということだ。最初の一本はバイオ/ネットな非データ手順で僕が選んだ方。少し遅れたもう一本は抽象データ型でこっちの方がずっと賑わっている)}}
ここで[[抽象データ型]]に対しての、非データ手順(non-data-procedure)というワードが登場する。振る舞いを通してデータを扱うというデータ抽象の概念を、更に抽象化したものが非データであり、[[代数学]]で言う[[写像]]だけでデータを表現するという概念を指している。これにケイの[[生物学]]専攻を背景にしたバイオ/ネット(bio/net)なる考えが加えられている。
{{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)に関連付けられるものとしては、[[代数的構造]]、[[圏論]]の[[射 (圏論)|射]]や[[関手]]の構造、{{仮リンク|Futuresとpromises|en|Futures and promises}}、{{仮リンク|ポイントフリースタイル|en|point-free style}}、[[プロセス代数]]、[[アクターモデル]]、自由[[モナド (プログラミング)|モナド]]などが挙げられる。
{{Quotation|The people who liked objects as non-data were smaller in number,<br/>(非データとしてのオブジェクトを好む者は少なかった、)}}
ここで歴史に戻る。1970年前後になると[[ソフトウェア危機]]としても語られるプログラム規模拡大に対応するために、サブルーチンとデータをまとめた[[モジュール|プログラムモジュール]]という機能が登場した。それと同時期の1967年に[[オルヨハン・ダール]]らは[[クラス (コンピュータ)|クラス]]という機能を備えた[[Simula|Simula67]]を開発し、1969年から[[エドガー・ダイクストラ]]は抽象データ構造という概念を備えた[[構造化プログラミング]]を提唱した。1974年から[[IBM|IBM社]]中心の研究者たちが[[構造化分析設計技法|構造化分析/設計]]と総称される技法を発表し、構造化プログラミングはこちらに取って代わられた。1972年からアラン・ケイはメッセージングという概念を備えたオブジェクト指向を誕生させている。オブジェクト指向は後に[[クラスベース|クラス・パラダイム]]にマウントされている。


[[構造化プログラミング|構造化設計]]は、サブルーチン複合体とデータ構造を扱っている具象データ(concrete data)技術である。Simula発のクラスとダイクストラ発の抽象データ構造は、プログラムモジュールに[[カプセル化]]・[[継承 (プログラミング)|継承]]・[[多態性]]を備えて抽象体として扱おうとする抽象データ(abstract data)技術である。そしてアラン・ケイ本来のオブジェクトとは、プログラムモジュールを[[生物学]]と[[代数学]]の観点から再解釈した非データ(non data)技術であった。構造化開発は1980年代までの主流であり、続けてオブジェクト指向が主流になったが、現在においてもクラスをただのデータとメソッドの複合体として扱っているようなオブジェクト指向は、構造化開発と大差ないものになり「具象データ」から「抽象データ」への思考転換の難しさを物語っている。モジュールの抽象化が提唱され始めたのは1970年代であったが、同時期にアラン・ケイは「抽象データ」を更に抽象化した「非データ」を構想していた。
'''(3)'''と'''(5)'''によってオブジェクトとは、データとメソッドの複合体である事が示されている。これは[[Simula|Simula 67]]のオブジェクト概念を踏襲している。'''(4)'''によってオブジェクトの実装は、クラスという定義情報とそれを実メモリに展開したインスタンスで為される事が示されている。これもSimula 67の特徴に準じているが、更にクラスもオブジェクトとする事でいわゆるメタデータの扱いにも言及している。'''(6)'''の''eval''(''evaluate'')とはソフトウェア工学では演算して結果値を出す意味の言葉であり、プログラムは任意のオブジェクトから開始され、後はメッセージによるオブジェクト間の相互作用で処理が実行される事を示している。プロセスが各オブジェクトを扱うのではなく、イメージ的にオブジェクトの振る舞い及びその振る舞いのトリガーになるオブジェクト同士の引き合わせ(''communication'')を意味するメッセージングがそのままプロセスとなる事を強調していた。


=== 2020年の言及 ===
なおこれは同時に要点でもあるが、アラン・ケイが最初に示したのは(1)から(3)までであり、(4)から(6)は実際のコーディングスタイルを掴ませる為にあえて付け加えられたものだった。つまり、オブジェクト指向の要約は(1)から(3)までで事足りるという。これについても後述する。


Q&Aサイトの[[Quora]]で「1966~67年のオブジェクト指向という造語を発したアラン・ケイに誰かが影響を与えていたのか?」という質問に対して本人がこう回答している。なお、強調されている“rotation”は「The Early History of Smalltalk」などにその経緯が記された1966年頃の彼自身による“オブジェクト”の、特にソフトウエアの基本構成単位としての発見(念のため、この時点ではSimulaはまだ「オブジェクト」ではなく後述のように相当するエンティティを「プロセス」という用語で表現していた)とその後の彼の中での発想の大転換を意味する。{{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年代、配列より複雑なソフトウェア構成体はしばしばオブジェクトと呼ばれており、僕のスキームにあった手続き付きの構造体もそうだった。私の中での“発想の転換”が起こった後、今何をしているのかと尋ねられた僕は愚かにもこう言った。オブジェクト指向プログラミングと。)<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はプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい?)
オブジェクト指向を提唱する中で[[アラン・ケイ]]は[[LISP]]の影響を受けた事を言及しているが、具体的に参考とされたのは、''lambda''のキーワードで表現される[[高階関数]]の仕組みと、''atomと定義される''データ表現であったという<ref name="EarlyHistoryOfSmalltalk" />。なお、他方では[[Simula|Simula 67]]の言語仕様を始めて見た際に「あれは''object-oriented''だな!」と語ったというエピソードも紹介されており、[[Smalltalk]]公開当時のケイは何か含む所があって[[Simula|Simula 67]]に対する言及を恐らく意図的に避けていたが、現実的にはLISPの''atom''とSimula 67の''object''&''class''の双方を参考にしてデータ(変数またはプロパティ)とコード(関数またはメソッド)の複合体であるオブジェクトというプログラム概念を考案したと見るのが衆目の一致する所となっている。80年代に入り[[C++]]が公開されると、Simula 67にも言及するようになった代わりに今度はC++をオブジェクト指向の観点から語ろうとはしなかったが、その言語仕様に内包される[[抽象化 (計算機科学)|抽象化]]のプログラミング概念については度々触れていた。
}}


==脚注==
== 脚注 ==
{{Reflist}}
'''出典'''{{Reflist}}


==関連項目==
==関連項目==
*[[ソフトウェ工学]]
*[[アラン・ケイ]]
*[[Smalltalk]]
*[[オブジェクト関係データベース]]
*[[LISP]]
*[[オブジェクト関係マッピング]]
*[[Simula]]
*[[NEXTSTEP]] - オブジェクト指向オペレーティングシステム
*[[ジェトモデル化技法]]
*[[ダイナク]]
*[[Alto|Xerox Alto]]
*[[Booch法|ブーチメソッド]]
*[[GUI]]
*[[オブジェクト指向ソフトウェア工学]]
*[[仮想マシン]]
*[[統一モデリング言語|UML(統一モデリング言語)]]
*[[CRCカード]]
*[[アクターモデル]]
*[[アクターモデル]]
*[[アスペクト指向]]
*[[エージェント指向]]


==外部リンク==
==外部リンク==
{{Wikibooks|オブジェクト指向|オブジェクト指向}}
*[http://msdn.microsoft.com/ja-jp/academic/cc998612.aspx オブジェクト指向とは: 開発者向け技術情報]
*[http://msdn.microsoft.com/ja-jp/academic/cc998612.aspx オブジェクト指向とは: 開発者向け技術情報]


{{Wikibooks|オブジェクト指向|オブジェクト指向}}
{{プログラミング言語の関連項目}}
{{プログラミング言語の関連項目}}

{{DEFAULTSORT:おふしえくとしこう}}
{{DEFAULTSORT:おふしえくとしこう}}
[[Category:オブジェクト指向|*]]
[[Category:オブジェクト指向|*]]
[[Category:ソフトウェア工学]]
[[Category:ソフトウェア工学]]
[[Category:対象]]
[[Category:アラン・ケイ]]

2024年6月22日 (土) 04:37時点における最新版

オブジェクト指向(オブジェクトしこう、: object-oriented)は、ソフトウェア開発コンピュータプログラミングのために用いられる考え方である。元々は特定のプログラミングパラダイムを説明するために考案された言葉であり、その当時の革新的技術であったGUI(グラフィカル・ユーザーインターフェース)とも密接に関連していた。明確な用語としては1970年代に誕生し、1981年頃から知名度を得て、1986年頃からソフトウェア開発のムーブメントと化した後に、1990年頃にはソフトウェア開発の総合技術としての共通認識を確立している。ソフトウェア開発における一つの標語のような扱い方もされている。

オブジェクトとは、プログラミング視点ではデータ構造とその専属手続きを一つにまとめたものを指しており、分析/設計視点では情報資源とその処理手順を一つにまとめたものを指している。データプロセスを個別に扱わずに、双方を一体化したオブジェクトを基礎要素にし、メッセージと形容されるオブジェクト間の相互作用を重視して、ソフトウェア全体を構築しようとする考え方がオブジェクト指向である。

オブジェクト指向の来歴

[編集]
アラン・ケイ

オブジェクト指向プログラミングの発案

[編集]

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

オブジェクト指向開発の始動

[編集]

1986年からACM(計算機協会)がOOPSLA(オブジェクト指向会議)を年度開催するようになり、オブジェクト指向はコンピュータサイエンスの一つのムーブメントになった。OOPSLA初期のチェアパーソンは、Smalltalkが生まれたゼロックス社パロアルト研究所のフェローが務めることが多かった。Smalltalkは正確にはプログラミング言語GUIフレームワークを合わせた統合開発運用環境であり、ゼロックスAlto機上のOSまたはミドルウェアとして制作されていた。ゼロックスAltoGUIを初めて汎用的にサポートしたコンピュータとOSであり、かのスティーブ・ジョブスを啓発してMacintoshのモデルになったことはよく知られている。1980年代前半のコンピュータ界隈は、CUI(キャラクタ・ユーザーインターフェース)からGUI(グラフィカル・ユーザーインターフェース)への過渡期であったので、すでにプログラミングパラダイムとGUIデザイン理論をミックスさせていたオブジェクト指向は、その当時における次世代的なソフトウェア開発技術になり得るものとして関心を集めていた。

また別の背景としては、1970年代からの主流である構造化開発が拡張を続けていた中で、様々なデータ構造図データフロー図の技法およびデータモデリングの手法がやや乱立気味になっていたという事情があり、その見直しを兼ねて一からの仕切り直しによるソフトウェア開発技術の標準化(standardization)を図りたいとする産業界や計算機科学界の思惑もあった。オブジェクト指向はそのためのスローガンとしても最適であった。こうした経緯から技術的以外の意味も与えられたオブジェクト指向は同時にバズワード化することにもなっている。構造化開発機能を中心にして機能データ構造を個別にデザインする段階的詳細化を基礎にしていたのに対し、オブジェクト指向はデータと機能を一つにまとめたobjectをソフトウェアデザインの中心にした上でエドガー・ダイクストラ発案の抽象データ構造及びバーバラ・リスコフ提唱の抽象データ型を基礎にしていた。これは前述のSimulaスタイル由来である。オブジェクト指向開発(object-oriented development)という言葉を最初に引用したのは、1986年のソフトウェア技術者グラディ・ブーチであったとされる。その最初の活用対象になったのは、データベース開発とオペレーティングシステム開発およびユーザーインターフェース設計であった。

オブジェクト指向方法論の進展

[編集]

OOPSLAの開催と連動してまずオブジェクト指向設計(OOD)とオブジェクト指向分析(OOA)が立ち上げられた。これは構造化開発のSDとSAに倣っていた。1980年代後半からOOPSLA界隈の識者たちによって様々な分析メソッドと設計メソッドが発表されるようになった。この分析/設計メソッドから導出される概念モデルを、形式的にチャート化ないしダイアグラム化するという作業がモデリングであり、構造化開発でも機能モデルデータモデル実体関連モデル(ER図)などが存在していたが、抽象化を尊ぶオブジェクト指向開発では特にこのモデリングが重視されたのが特徴である。1988年のオブジェクト指向システム分析(OOSA)、1990年からのCoad&Yourdon法、1991年のBooch法オブジェクトモデル化技法(OMT)、1992年のオブジェクト指向ソフトウェア工学(OOSE)、1993年のフュージョンメソッドとMartin&Odell法といった数々のオブジェクト指向方法論(object-oriented methodology)によるモデリング手法が発表され、いずれも形式言語化されていたのでオブジェクト指向では、モデリング言語プログラミング言語が並んでソフトウェア開発の両輪になった。

1990年前後から認知されるようになったオブジェクト指向方法論とは、要求分析概念設計モデリングプログラミングといった一連の工程を総括的に形式化した理論体系であり、ソフトウェア開発の総合技術としてのオブジェクト指向を体現していた。1994年にモデリング言語をプログラム設計に直接適用したGOFデザインパターンが初回発表された。Booch法とOMTとOOSEの考案者(スリーアミーゴス)は、後のIBMブランドになるラショナルソフトウェアで合流して統一モデリング言語(UML)を制作し、1995年のOOPSLAで初回発表した。オブジェクト指向はソフトウェア開発工程の分野にも広がり、モデル駆動工学ドメイン固有言語リファクタリングアジャイルソフトウェア開発といった数々のトピックもOOPSLAから誕生している。IBMラショナルはオブジェクト指向開発工程フレームワークを標榜するラショナル統一プロセスを2003年に公開した。

1989年にはIBM社Apple社、ヒューレットパッカード社サンマイクロシステムズ社アメリカン航空などの11社がコンピュータ産業共同事業団体OMG(Object Management Group)を設立した。その主な目的は、企業システムネットワークの基盤になる分散コンピューティングを構築するための分散オブジェクト設計の標準化を図ることであった。ここでのオブジェクトもデータとメソッドの複合体と定義されていた。1991年に分散オブジェクトの規格パラダイムとなるCORBAが発表された。1997年にOMGの標準モデリング言語はUMLに策定された。モデリングの形式体系化に力を注いでいたOMGはモデル駆動工学のメソッド確立を進めて、2001年にモデル駆動アーキテクチャを発表している。

オブジェクト指向の種類

[編集]

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

[編集]

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.
(双方の事例において私達は、オブジェクト(対象)を第一とし、欲求を第二とする。これは高い満足度で具象と抽象を一体化する)

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

1990年代の言及

[編集]

1992年にACMからプログラミング言語史編纂の一環として執筆を依頼されたアラン・ケイは、翌93年の「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の設計―及び存在―とは、私たちの思い描ける全てが、自己の状態とプロセスの結合を内部隠蔽した個々の振る舞い組立ブロックの再帰構成によって表現され、徹底的なメッセージの交換のみによって処理されるということだ。)

再帰構成すなわち再帰の概念は、後続文にも繰り返し登場している。もっとも再帰は一般知識であり、例えばジョン・マッカーシー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年にアラン・ケイはオブジェクト指向の貢献でチューリング賞を受賞し、知人から改めてオブジェクト指向の意味を尋ねられたケイは以下のようにメール返信している[5]。このメールは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はプロセスと呼んでいた。こっちがよかったな。プロセス指向プログラミングの方がずっと良かったと思わないかい?)

脚注

[編集]

出典

関連項目

[編集]

外部リンク

[編集]