コンテンツにスキップ

「オブジェクト指向プログラミング」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
G000001 (会話 | 投稿記録)
恐らく手元に保存していたテキストを貼り付けて巻き戻しを実施したのだと思いますが、他の方の編集も巻き添えて消えてしまっていますので一旦戻します。つもりやもり (会話) による ID:82968896 の版を取り消し
タグ: 取り消し サイズの大幅な増減
もうLISPに触れる記事は書きませんので(;_;)大量削除、大量コメントアウト、やっつけ項目列挙による記事破壊はやめてください(T_T)ご自分で大量コメントアウトしておきながら、他の方の編集を巻き込んで~などと宣うのは明らかに意地悪目的が分かって悲しいです(・_・。)
タグ: サイズの大幅な増減 ビジュアルエディター
66行目: 66行目:
[[Simula]]を研究対象にしていた[[ベル研究所|AT&Tベル研究所]]の計算機科学者[[ビャーネ・ストロヴストルップ]]は、1979年からクラス付きC言語の開発に取り組み、1983年に「[[C++]]」を公開した。C++で実装された[[クラス (コンピュータ)|クラス]]は、Simula譲りの[[継承 (プログラミング)|継承]]と仮想関数に加えて、[[レキシカルスコープ]]の概念をクラス構造に応用した[[アクセスコントロール]]を備えていた。C++で確立されたアクセスコントロールはカプセル化の元になったがコードスタイル上ほとんどザル化されており、その理由からストロヴストルップ自身もC++は正しくない(''not just'')オブジェクト指向言語であると明言している。1986年にソフトウェア技術者[[バートランド・メイヤー]]が開発した「[[Eiffel]]」の方は、正しいオブジェクト指向を標榜してクラスのデータ抽象を遵守させるコードスタイルが導入されていた。クラスメンバ(フィーチャー)は属性、手続き、関数の三種構成で、手続きで属性を変更し関数で属性を参照するという形式に限定されており、これは抽象データ型の[[セマンティクス|振る舞い意味論]]に沿った実装であった。アクセスコントロールはモジューラプログラミングの情報隠蔽に沿った方式になり、仮想関数機能は延期手続き/関数として実装された。{{Quotation|''I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.''
[[Simula]]を研究対象にしていた[[ベル研究所|AT&Tベル研究所]]の計算機科学者[[ビャーネ・ストロヴストルップ]]は、1979年からクラス付きC言語の開発に取り組み、1983年に「[[C++]]」を公開した。C++で実装された[[クラス (コンピュータ)|クラス]]は、Simula譲りの[[継承 (プログラミング)|継承]]と仮想関数に加えて、[[レキシカルスコープ]]の概念をクラス構造に応用した[[アクセスコントロール]]を備えていた。C++で確立されたアクセスコントロールはカプセル化の元になったがコードスタイル上ほとんどザル化されており、その理由からストロヴストルップ自身もC++は正しくない(''not just'')オブジェクト指向言語であると明言している。1986年にソフトウェア技術者[[バートランド・メイヤー]]が開発した「[[Eiffel]]」の方は、正しいオブジェクト指向を標榜してクラスのデータ抽象を遵守させるコードスタイルが導入されていた。クラスメンバ(フィーチャー)は属性、手続き、関数の三種構成で、手続きで属性を変更し関数で属性を参照するという形式に限定されており、これは抽象データ型の[[セマンティクス|振る舞い意味論]]に沿った実装であった。アクセスコントロールはモジューラプログラミングの情報隠蔽に沿った方式になり、仮想関数機能は延期手続き/関数として実装された。{{Quotation|''I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.''
<br />(僕はオブジェクト指向という言葉を作ったけど、C++(のような言語)は考えていなかった)|Alan Kay}}1986年から[[Association for Computing Machinery|ACM]]が[[OOPSLA|オブジェクト指向会議]](OOPSLA)を年度開催し、そのプログラミング言語セクションでは[[抽象データ型]]の流れを汲む[[クラス (コンピュータ)|クラス]]・パラダイムが主要テーマにされ、それを標準化するための数々のトピックが議題に上げられている。[[モジュール性]]、情報隠蔽、[[抽象化 (計算機科学)|抽象化]]、再利用性、[[継承 (プログラミング)|階層構造]]、複合構成、実行時多態、[[動的束縛]]、[[総称型]]、[[ガベージコレクション|自動メモリ管理]]といったものがそうであり、参画した識者たちによる寄稿、出版、講演を通して世間にも広められた。そうした潮流の中で[[ビャーネ・ストロヴストルップ|ストロヴストルップ]]はデータ抽象の重要性を訴え、[[バーバラ・リスコフ|リスコフ]]は[[上位概念、下位概念、同位概念および同一概念|基底と派生]]に分けたデータ抽象の[[リスコフの置換原則|階層構造の連結関係]]について提言した。[[契約による設計]]を提唱する[[バートランド・メイヤー|メイヤー]]が1988年に刊行した『オブジェクト指向ソフトウェア構築』は名著とされ、Eiffelを現行の模範形とする声も多く上がった。ただしこれは学術寄りの意見でもあったようで、世間のプログラマの間では厳格なEiffelよりも柔軟で融通の利くC++の人気の方が高まっていた。他方でオブジェクト指向本来の原点であるメッセージ・メタファに忠実であろうとする動きもあり、1984年に開発された「[[Objective-C]]」はSmalltalkをモデルにしてそれを平易化した言語であった。そのメッセージレシーバーは静的なメソッド機構優先の動的ディスパッチ機構という方式で実装された。メッセージレシーバの仕組みは[[遠隔手続き呼出し]]/[[Object Request Broker|オブジェクト要求ブローカー]]の実装に適していたので[[分散システム]]とオブジェクト指向の親和性を認識させることになった。
<br />(僕はオブジェクト指向という言葉を作ったけど、C++(のような言語)は考えていなかった)|Alan Kay}}1986年から[[Association for Computing Machinery|ACM]]が[[OOPSLA|オブジェクト指向会議]](OOPSLA)を年度開催し、そのプログラミング言語セクションでは[[抽象データ型]]の流れを汲む[[クラス (コンピュータ)|クラス]]・パラダイムが主要テーマにされ、それを標準化するための数々のトピックが議題に上げられている。[[モジュール性]]、情報隠蔽、[[抽象化 (計算機科学)|抽象化]]、再利用性、[[継承 (プログラミング)|階層構造]]、複合構成、実行時多態、[[動的束縛]]、[[総称型]]、[[ガベージコレクション|自動メモリ管理]]といったものがそうであり、参画した識者たちによる寄稿、出版、講演を通して世間にも広められた。そうした潮流の中で[[ビャーネ・ストロヴストルップ|ストロヴストルップ]]はデータ抽象の重要性を訴え、[[バーバラ・リスコフ|リスコフ]]は[[上位概念、下位概念、同位概念および同一概念|基底と派生]]に分けたデータ抽象の[[リスコフの置換原則|階層構造の連結関係]]について提言した。[[契約による設計]]を提唱する[[バートランド・メイヤー|メイヤー]]が1988年に刊行した『オブジェクト指向ソフトウェア構築』は名著とされ、Eiffelを現行の模範形とする声も多く上がった。ただしこれは学術寄りの意見でもあったようで、世間のプログラマの間では厳格なEiffelよりも柔軟で融通の利くC++の人気の方が高まっていた。他方でオブジェクト指向本来の原点であるメッセージ・メタファに忠実であろうとする動きもあり、1984年に開発された「[[Objective-C]]」はSmalltalkをモデルにしてそれを平易化した言語であった。そのメッセージレシーバーは静的なメソッド機構優先の動的ディスパッチ機構という方式で実装された。メッセージレシーバの仕組みは[[遠隔手続き呼出し]]/[[Object Request Broker|オブジェクト要求ブローカー]]の実装に適していたので[[分散システム]]とオブジェクト指向の親和性を認識させることになった。

=== SmalltalkとSelf ===
パロアルト研究所では、Smalltalk方言を発端にした「Self」が1986年に開発スタートし、その開発チームが移籍したサン社から1990年に一般リリースされた。
Selfは、後にプロトタイプベースと呼ばれるオブジェクト指向スタイルを開拓した。


=== コンポーネントとネットワーク(1989 - 97) ===
=== コンポーネントとネットワーク(1989 - 97) ===

ネットワーク技術の発展に連れて、データとメソッドの複合体であるオブジェクトの概念は、[[分散システム]]構築のための基礎要素としての適性を特に見出される事になり、[[IBM|IBM社]]、[[アップル (企業)|アップル社]]、[[サン・マイクロシステムズ|サン社]]などが1989年に共同設立した[[Object Management Group|OMG]]は、企業システムネットワーク向け分散オブジェクトプログラミングの標準規格となる[[CORBA]]を1991年に公開した。その前年に[[マイクロソフト|マイクロソフト社]]は[[ウェブアプリケーション]]向けの分散オブジェクト技術となる[[OLE]]を発表し、1993年には[[Component Object Model|COM]]と称する[[ソフトウェアコンポーネント]]仕様へと整備した。この[[Component Object Model|COM]]の利用を眼目にしてリリースされた「[[Microsoft Visual C++|Visual C++]]」「[[Visual Basic]]」は[[World Wide Web|ウェブ]]時代の新しいプログラミング様式を普及させる先駆になった。この頃に[[抽象データ型]]のメソッドを通したデータ抽象、データ隠蔽、[[アクセスコントロール]]および分散オブジェクトの[[インタフェース (情報技術)|インターフェース]]機構によるプログラムの抽象化といった概念は、[[カプセル化]]という用語にまとめられるようになった。クラスの[[継承 (プログラミング)|継承]]が最もオブジェクト指向らしい機能と見なされていたのが当時の特徴であった。継承構造を利用した振る舞いサプタイピングは[[多態性]]という用語に包括された。こうしていわゆるオブジェクト指向の三大要素がやや漠然と確立されている。1996年にサン社がリリースした「[[Java]]」は三大要素が強く意識された[[クラスベース]]であり、その中の分散オブジェクト技術は[[JavaBeans|Beans]]と呼ばれた。類似の技術としてアップル社も[[MacOS]]上で[[Objective-C]]などから扱える[[Cocoa]]を開発している。また、1994年から96年にかけて「[[Python]]」「[[Ruby]]」「[[JavaScript]]」といったオブジェクト指向スクリプト言語がリリースされ、従来の[[クラスベース]]に対する新しい[[プロトタイプベース]]を定着させている。1994年の[[ギャング・オブ・フォー (情報工学)|GOF]][[デザインパターン (ソフトウェア)|デザインパターン]]の発表と、1997年に[[Object Management Group|OMG]]が標準[[モデリング言語]]として採用した[[統一モデリング言語|UML]]は、オブジェクト指向プログラミングの標準化を促進させた。{{Quotation|''... 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を触媒にした二本の道があった。最初の一本はバイオネットな非データ手法で僕が選んだ方。少し遅れたもう一本は抽象データ型、こっちの方がずっと賑わっている。)|Alan Kay}}
ネットワーク技術の発展に連れて、データとメソッドの複合体であるオブジェクトの概念は、[[分散システム]]構築のための基礎要素としての適性を特に見出される事になり、[[IBM|IBM社]]、[[アップル (企業)|アップル社]]、[[サン・マイクロシステムズ|サン社]]などが1989年に共同設立した[[Object Management Group|OMG]]は、企業システムネットワーク向け分散オブジェクトプログラミングの標準規格となる[[CORBA]]を1991年に公開した。その前年に[[マイクロソフト|マイクロソフト社]]は[[ウェブアプリケーション]]向けの分散オブジェクト技術となる[[OLE]]を発表し、1993年には[[Component Object Model|COM]]と称する[[ソフトウェアコンポーネント]]仕様へと整備した。この[[Component Object Model|COM]]の利用を眼目にしてリリースされた「[[Microsoft Visual C++|Visual C++]]」「[[Visual Basic]]」は[[World Wide Web|ウェブ]]時代の新しいプログラミング様式を普及させる先駆になった。この頃に[[抽象データ型]]のメソッドを通したデータ抽象、データ隠蔽、[[アクセスコントロール]]および分散オブジェクトの[[インタフェース (情報技術)|インターフェース]]機構によるプログラムの抽象化といった概念は、[[カプセル化]]という用語にまとめられるようになった。クラスの[[継承 (プログラミング)|継承]]が最もオブジェクト指向らしい機能と見なされていたのが当時の特徴であった。継承構造を利用した振る舞いサプタイピングは[[多態性]]という用語に包括された。こうしていわゆるオブジェクト指向の三大要素がやや漠然と確立されている。1996年にサン社がリリースした「[[Java]]」は三大要素が強く意識された[[クラスベース]]であり、その中の分散オブジェクト技術は[[JavaBeans|Beans]]と呼ばれた。類似の技術としてアップル社も[[MacOS]]上で[[Objective-C]]などから扱える[[Cocoa]]を開発している。また、1994年から96年にかけて「[[Python]]」「[[Ruby]]」「[[JavaScript]]」といったオブジェクト指向スクリプト言語がリリースされ、従来の[[クラスベース]]に対する新しい[[プロトタイプベース]]を定着させている。1994年の[[ギャング・オブ・フォー (情報工学)|GOF]][[デザインパターン (ソフトウェア)|デザインパターン]]の発表と、1997年に[[Object Management Group|OMG]]が標準[[モデリング言語]]として採用した[[統一モデリング言語|UML]]は、オブジェクト指向プログラミングの標準化を促進させた。{{Quotation|''... 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を触媒にした二本の道があった。最初の一本はバイオネットな非データ手法で僕が選んだ方。少し遅れたもう一本は抽象データ型、こっちの方がずっと賑わっている。)|Alan Kay}}


== 代表的なオブジェクト指向言語 ==
== 代表的なオブジェクト指向言語 ==
オブジェクト指向を総体的または部分的にサポートする機能を備えたプログラミング言語の公開は、1980年代後半から顕著となった<ref>{{cite web|url=http://oopsla.org/oopsla-history/ |title=OOPSLA History |accessdate=2021-03-01}}</ref><ref>{{cite web|url=https://ecoop.org/conferences.html |title=ECOOP Conference Series|accessdate=2021-03-01}}</ref>。<!--OOP言語の分類法は複数あるが、Smalltalkをルーツとするメッセージパッシングの構文が重視されてるか否かで大別される事が多い。そうでないものがOOP言語の主流となっており「C++」「Java」「C#」「Swift」などがその代表とされる。メッセージパッシングを重視するOOP言語には「Smalltalk」「Objective-C」「Self」などがある。-->言語仕様の中でオブジェクト指向の存在感が比較的高い代表的なプログラミング言語を以下に列挙する。


* [[Simula|Simula 67]] 1967年
* [[Simula|Simula 67]] 1967年
<!-- :1962年に公開された[[Simula]]の後継バージョンであり、[[クラス (コンピュータ)|クラス]]のプログラム概念を導入した最初の言語である。物理モデルを解析するシミュレーション制作用に開発されたもので、クラスをメモリに展開したオブジェクトはその観測対象要素になった。Simulaのクラスは、一つのローカル変数構造と複数のプロシージャをまとめたミニモジュールと言えるものであったが、継承と仮想関数という先進的な設計を備えていた事でオブジェクト指向言語の草分けと見なされるようになった。[[クラスベース]]の源流である。 -->
* [[Smalltalk]] 1972年
* [[Smalltalk]] 1972年
<!-- :[[メッセージパッシング|メッセージング]]のプログラム概念を導入した最初の言語。数値、真偽値、文字列から変数、コードブロック、メタデータまでのあらゆるプログラム要素をオブジェクトとするアイディアを編み出した最初の言語であり、[[プロトタイプベース]]の源流にもなった。オブジェクト指向という言葉はSmalltalkの言語設計を説明する中で生み出された。オブジェクトにメッセージを送るという書式であらゆるプロセスを表現することが目標にされている。動的ディスパッチと[[ダイナミックバインディング|動的バインディング]]相当の機構である[[メッセージ転送|メッセージレシーバー]]と[[委譲|デリゲーション]]は、後年の[[デザインパターン (ソフトウェア)|デザインパターン]]のモデルにもされた。GUI運用環境に統合された専用のランタイム環境上で動作させる設計も模範にされ、これは後に[[仮想マシン]]や[[仮想実行システム]]と呼ばれるものになる。-->
* [[C++]] 1983年
* [[C++]] 1983年
<!--:[[C言語]]に[[クラスベース]]のオブジェクト指向を追加したもの。Simulaの影響を受けている。[[静的型付け]]の[[クラス (コンピュータ)|クラス]]が備えられてカプセル化、継承、多態性の三仕様を実装している。カプセル化ではアクセス修飾子とフレンド指定子の双方から可視性を定義できる。継承は多重継承、オーバーライド制約用の継承可視性、[[菱形継承問題]]解決用の[[仮想継承]]も導入されている。多態性は[[仮想関数]]によるサブタイプ多相、[[テンプレート (プログラミング)|テンプレートクラス&関数]]によるパラメトリック多相、[[多重定義|関数&演算子オーバーロード]]によるアドホック多相が導入されている。元がC言語であるため、オブジェクト指向から逸脱したコーディングも多用できる点が物議を醸したが、その是非はプログラマ次第であるという結論に落ち着いた。-->
* [[Objective-C]] 1984年
* [[Objective-C]] 1984年
<!--:[[C言語]]に[[メッセージパッシング|メッセージング]]ベースのオブジェクト指向を追加したもの。こちらはSmalltalkの影響を受けており、それに準じた[[メッセージパッシング]]の書式が備えられた。メッセージを受け取るクラスの定義による[[静的型付け]]と共に、メッセージを[[委譲]]するオブジェクトの実行時決定による[[動的型付け]]も設けられている。オブジェクト指向的にはC++よりも正統と見なされた。[[制御構造|制御構造文]]が追加され、メッセージ構文も平易化されており、Smalltalkよりも扱いやすくなった。-->
* [[Object Pascal]] 1986年
* [[Object Pascal]] 1986年
<!--:[[Pascal]]にクラスベースのオブジェクト指向を追加したもの。当初はモジュールのデータ隠蔽的なカプセル化、単一継承、仮想関数による多態性という基本的なものだった。静的型付け重視である。[[ニクラウス・ヴィルト|ヴィルト]]監修の[[アップル (企業)|アップル社]]による初回バージョンを土台にして様々な企業団体による派生版が公開されており、その特徴と機能追加も様々である。-->
* [[Eiffel]] 1986年
* [[Eiffel]] 1986年
<!--:[[C++]]の柔軟性と融通性とは正反対のオブジェクト指向言語。[[クラスベース]]で[[静的型付け]]重視である。[[契約プログラミング|契約による設計]]準拠のきめ細かな[[表明|アサーション]]と[[例外処理]]の導入で堅牢性が高められている。クラスメンバ(フィーチャー)はデータ、アクセッサ、ミューテイタの三種限定で[[多重定義|オーバーロード]]はできない。カプセル化の可視性は自身に依存するクラス(クライアント)を定義する形で決められる。多重継承可能であり、クラス間の繋がりを[[仮想継承]]機能、各種[[オーバーライド]]指定子、名前衝突を解決するリネーミング機能などで綿密に設定できる。多態性は[[仮想関数|延期関数/手続き]](サブタイプ多相)と[[ジェネリックプログラミング|ジェネリシティ]](パラメトリック多相)である。[[ガーベジコレクション]]機能が初めて導入されたオブジェクト指向言語でもある。-->
* [[Self]] 1987年
* [[Self]] 1987年
* [[Common Lisp Object System]] 1988年
<!-- :[[メッセージパッシング|メッセージング]]ベースのオブジェクト指向言語で当初はSmalltalkの方言として開発された。プロトタイプからインスタンスを複製して、プロパティとメソッドを[[ダイナミックバインディング|動的バインディング]]できるという仕様が備えられている。[[プロトタイプベース]]というパラダイムはこのSelfから認知されるようになった。[[動的型付け]]重視である。Smalltalkと同様に専用のランタイム環境上で実行され、GUI運用環境の構築も目標にしていた。Selfのランタイム環境は[[実行時コンパイラ]]機能を初めて実装したことで知られており画期的な処理速度を実現している。この技術は[[Java仮想マシン]]の土台になった。-->
* [[Common Lisp]]([[CLOS]]) 1988年(ANSI規格化は1994年)
<!-- :[[クラスベース]]のオブジェクト指向。メソッド記述の関数呼び出し形式への統合、[[多重ディスパッチ]]、クラスの動的な再定義等を特徴とする。-->
* [[Python]] 1994年
* [[Python]] 1994年
<!-- :[[プロトタイプベース]]のオブジェクト指向スクリプト言語。[[基本データ型]]や[[コンテナ (データ型)|コレクション型]]などよく使われるデータ要素を全て組み込みのオブジェクトにしている。それらは[[手続き型プログラミング|手続き型]]スタイルでも気軽に扱える。コレクション型を扱うのに適した[[関数型プログラミング|関数型]]構文も導入されている。関数/変数のオブジェクトは自由にプロパティとメソッドを付け足し付け替え可能である。オブジェクトは[[ダックタイピング]]で型判別されるので変数/関数の型宣言と型注釈は撤廃されている。ゆえに[[動的な型付け|動的型付け]]重視である。Pythonのプロトタイプはクラスと呼ばれている。多重継承可能であり親クラス要素のサーチ順序はC3線形化で解決されている。多態性は事実上メソッドの動的バインディングになっている。カプセル化は軽視されている。後期バージョンで型ヒントが追加され、それに伴い[[ジェネリクス]]も導入された。-->
* [[Java]] 1995年
* [[Java]] 1995年
<!-- :[[C++]]をモデルにしつつ堅牢性とセキュリティを重視した[[クラスベース]]のオブジェクト指向言語。静的型付け重視である。パッケージ中心のカプセル化、単一のみの継承、仮想関数と多重実装可な[[インタフェース (抽象型)|インターフェース]]による多態性と、基本に忠実なクラスベースである。C++風の[[ポインタ (プログラミング)|ポインタ]]と値型インスタンスは除外されて参照型インスタンスに統一した。[[例外処理]]を整備し[[演算子オーバーロード]]を除外した。オブジェクト指向と[[マルチスレッド]]の調和が図られ、[[ソフトウェアコンポーネント|コンポーネント指向]]による動的クラスローディングの存在感が高められている。クラスメタデータを操作できる[[リフレクション (情報工学)|リフレクション]]は初期から採用された。中期から[[ジェネリクス]](パラメトリック多相)と[[アノテーション|メタアノテーション]](アドホック多相)が導入され、ラムダ式と関数型インターフェースを軸にした[[関数型言語|関数型構文]]も採用された。[[仮想マシン]]上で実行される。[[仮想マシン]]と[[ガーベジコレクション]]の技術は比較的高度と見なされている。-->
* [[Delphi]] 1995年
* [[Delphi]] 1995年
<!-- :[[Object Pascal]]を発展させたもの。それと同様にこちらも基本に忠実なクラスベースで静的型付け重視であった。当初はデータベース操作プログラム開発を主な用途にして公開された。クラスとレコード([[構造体]])に同等の比重が置かれていた。一時期Javaの対抗馬になった。-->
* [[Ruby]] 1996年
* [[Ruby]] 1996年
<!-- :[[Python]]を意識して開発されたオブジェクト指向スクリプト言語。[[Smalltalk]]を一つの理想にしてより万人向けの言語を目指し、動的型付けを重視している。日本で誕生してグローバル化したプログラミング言語である。[[LISP]]とSmalltalkのメタプログラミング的なオブジェクト指向から、Pythonと[[JavaScript]]のプロトタイプベースなオブジェクト指向までのスタイルとコーディング手法を幅広く取り入れている。-->
* [[JavaScript]] 1996年
* [[JavaScript]] 1996年
<!--:[[プロトタイプベース]]のオブジェクト指向スクリプト言語。型宣言と型注釈を撤廃して[[ダックタイピング]]する[[動的な型付け|動的型付け]]重視である。すべてをオブジェクトにする[[Smalltalk]]の思想に忠実な言語であり、[[Python]]と似ているがそれよりも[[プロトタイプベース]]性質と[[関数型プログラミング]]性質を追求している。定数、変数、構造体、関数などが全て同性質のオブジェクトにされており、プロパティとメソッドを自由に付け足したり付け替えできるようにデザインされている。関数オブジェクトの構築と用い方がプログラミング上のキーポイントになっており、[[クロージャ]]、[[高階関数]]、[[第一級関数]]、デコレータ、[[パイプライン処理|パイプライン]]といった多種多様な働き方とその組み合わせを柔軟に表現できる。[[ウェブアプリケーション|WEBアプリケーション]]開発を主な用途にして公開されたのでオブジェクトは[[GUI]]パーツの構築にも最適化されている。[[ECMAScript]]として標準化されており、2015年版からは[[クラスベース]]向けの構文もサポートするようになった。-->
* [[C Sharp|C#]] 2000年
* [[C Sharp|C#]] 2000年
<!-- :[[Java]]を強く意識してマイクロソフト社が開発したクラスベースのオブジェクト指向言語。Javaよりも[[マルチパラダイムプログラミング言語|マルチパラダイム]]の性質が強化されている。C++譲りの柔軟性と融通的を残しながら様々な[[糖衣構文]]サポートも加えてコーディング上の利便性がより高められている。[[マルチスレッド]]仕様も整備されている。アドホック多相では拡張メソッド、インデクサ、演算子オーバーロードなどを備えている。パラメトリック多相では[[共変性と反変性 (計算機科学)|共変/反変]]も扱える[[ジェネリクス]]を備えている。サブタイプ多相はクラスは単一継承でインターフェースは多重実装と基本通りである。[[関数型言語|関数型構文]]も整備されており、特にメソッド参照機能であるデリゲートの有用性が高められている。デリゲートは[[イベント駆動型プログラミング|イベント駆動構文]]の平易な表現も可能にしている。基本は[[静的型付け]]であるが、動的束縛型と[[ダックタイピング]]による[[動的型付け]]の存在感が高められているので漸進的型付けの言語と見なされている。[[.NET Framework]]([[共通言語基盤]]=仮想実行システム)上で実行される。-->
* [[Scala]] 2003年
* [[Scala]] 2003年
<!-- :[[クラスベース]]のオブジェクト指向と[[関数型プログラミング]]を融合させた言語。[[クラス (コンピュータ)|クラス]]機構と関数型の[[型システム]]に同等の比重が置かれており静的型付け重視である。[[ミックスイン]]相当の[[トレイト]]と、[[共変性と反変性 (計算機科学)|共変/反変]]および抽象タイプメンバを扱える[[ジェネリクス]]を連携させた多態性が重視されておりオブジェクトを様々に[[派生型|派生型付け]]できる。シングルトンオブジェクトの役割が形式化されて従来のクラス静的メンバの新解釈にも用いられている。専用の定義書式により[[イミュータブル]]なオブジェクトが重視されている。上述の派生型付けスタイルとオブジェクト引数の[[逆写像|抽出]]構文と[[パターンマッチング|パターンマッチング式]]の併用連鎖計算は[[モナド (プログラミング)|モナド]]を彷彿とさせて独特の関数型スタイルを表現できる。[[Java仮想マシン]]上で動作するJavaテクノロジ互換言語である。-->
* [[Kotlin]] 2011年
* [[Kotlin]] 2011年
<!-- :静的型付けの[[クラスベース]]のオブジェクト指向であるが、[[手続き型プログラミング]]に回帰しており、クラス枠外の関数とグローバル変数の存在感が高められている。クラスはpublicアクセスとfinal継承がデフォルトにされて、カプセル化と継承が公然と軽視されている。これによりインスタンスは手続き型の関数の対象値としての役割が強められ、その操作をサポートする関数型構文も導入されている。仮想関数と抽象クラスによる多態性は標準通りである。[[Java仮想マシン]]上で動作するJavaテクノロジ互換言語である。-->
* [[TypeScript]] 2012年
* [[TypeScript]] 2012年
<!-- :[[JavaScript]]を強く意識してマイクロソフト社が開発したオブジェクト指向スクリプト言語。JavaScriptのプログラムを静的型付けで補完した言語である。[[クラスベース]]向けの構文と、[[関数型プログラミング]]の[[型システム]]のスタイルが加えられている。特に後者の性質が強調されている事から静的型付け重視である。継承構造によるサブタイプ多相はほぼ除外されており、[[ジェネリクス]]と型アノテーションでオブジェクトを扱うというパラメトリック多相とアドホック多相を重視するデザインになっている。オブジェクト指向ではあるが関数型の性格が強めである。-->
* [[Swift (プログラミング言語)|Swift]] 2014年
* [[Swift (プログラミング言語)|Swift]] 2014年
<!-- :[[Objective-C]]を発展させたものであるが、メッセージ構文は破棄されており、クラスベースのオブジェクト指向になっている。オブジェクトの[[イミュータブル|イミュータブル性]]重視の構文が採用されている。プロテクト可視性の削除によってクラスの縦並びの継承は軽視されており、プロトコルの横並びの多重実装を重視している。プロトコルは[[インタフェース (抽象型)|インターフェース]]と[[ミックスイン]]の中間的機能であり、インスタンスはプロトコルを基準にして型分類され、また抽象化される。プロトコルと[[ジェネリクス]]の連携による多態性が重視されている。モジュールの動的ローディングは不透明型の仕組みで補完されている。[[静的型付け]]重視である。-->


== デザインパターン ==
== 関連項目 ==

{{Wikibooks|オブジェクト指向|オブジェクト指向}}
=== 契約による設計 ===
* [[メッセージ (コンピュータ)]]
* [[メソッド (計算機科学)]]
* [[フィールド (計算機科学)]]
* [[インスタンス変数]]
* [[クラス変数]]
* [[クラス (コンピュータ)]]
* [[メタクラス]]
* [[インスタンス]]
* [[プロトタイプベース]]
* [[カプセル化]]
* [[継承 (プログラミング)|継承]]
* [[Is-a|Is-a関係]]
* [[Has-a|Has-a関係]]
* [[ミックスイン]]
* [[抽象クラス]]
* [[ダックタイピング]]
* [[委譲]]
* [[SOLID|SOLID原則]]
* [[プログラミング言語]]
* [[デザインパターン (ソフトウェア)|GOFデザインパターン]]
* [[オブジェクト指向モデリング]]
* [[オブジェクト指向分析設計]]
* [[オブジェクト指向]]
* [[オブジェクトデータベース]]
* [[トップダウン設計とボトムアップ設計]]
* [[オブジェクト関係マッピング]]
<!--
;プロトタイプ
:(''prototype'')の仕組みを中心にしたオブジェクト指向を[[プロトタイプベース]]と言う。<!--プロトタイプとは識別名&中間参照ペアの集合体を指す。この集合体は一般にフレームと呼ばれる。識別名&中間参照ペアの割り当て箇所は一般にスロットと呼ばれる。スロットにはデータとメソッドの識別名&中間参照ペアが代入されるので、プロトタイプはクラスと同様にデータとメソッドをまとめたものになる。プロトタイプは言語によってはクラスと呼ばれている。プログラマはシステムが提供する基底プロトタイプに、自由にデータとメソッドを付け足して任意の派生プロトタイプを作成できる。プロトタイプは「型」相当であり、それを複製する方式で生成されるインスタンスは「値」相当である。データとメソッドはその参照にインスタンスを必要とするものと、しないものに分かれる。前者はインスタンスメンバ、後者は静的メンバに相当するものである。インスタンスにも自由にデータとメソッドを付け足すことができる。インスタンスはそのプロトタイプへの参照を保持しており、プロトタイプはその親プロトタイプへの参照を保持している。これは継承相当の機能になっている。インスタンスへの自由なメンバ付け替えは多態性相当の機能になっている。ただしプロトタイプは動的な[[関数型言語]]由来の仕様なのでクラスベースOOPの三大要素とはまた違った視点から眺める必要がある。--><!-- 独自研究に思えます。出典がないので検証ができません -->
<!--
;[[コンストラクタ]]
:(''constructor'')はインスタンス生成時に呼び出されるそのクラスのメソッドである。インスタンスデータを任意の値で初期化するためのものであるが、その他の初期化コードも記述できる。プロトタイプベースではシステム提供プロトタイプが保持する生成用メソッドまたは生成用のグローバル関数がコンストラクタ相当になる。
;[[デストラクタ]]
:(''destructor'')はインスタンス破棄時に呼び出されるそのクラスのメソッドである。インスタンス破棄の影響を解決する任意の後始末コードを記述できる。インスタンスの破棄は占有メモリの解放を意味する。なお、ガーベジコレクタ実装言語ではファイナライザになっている事がある。プログラマが呼び出すデストラクタの方はその終了がメモリ解放に直結しているのに対し、ガーベジコレクタが呼び出すファイナライザの方はそうではない。
--><!-- OOP固有の話題ではないと思われます。出典がないので検証ができません -->
<!--
;[[This (プログラミング)|this参照]]
:(''this'')は言語によっては「self」や「me」とも呼ばれる。<code>instance.method()</code>の書式で呼び出されたメソッド内で、そのインスタンスのメンバを暗黙アクセスできるようにするための仕組みである。<code>instance</code>のアドレスが暗黙引数として<code>method</code>に渡されて、その<code>method</code>内で<code>this</code>となる。インスタンスのメンバアクセス時はこの<code>this</code>が自動的に付加され、例えば<code>data</code>がシステム内では<code>this.data</code>のように変換されている。メソッドはインスタンスの実体化元(量化元)クラスで定義されているものである。これは、データにメソッドを付属させるカプセル化を実現するための仕組みである。this参照に対するsuper参照(''super'')は、サブクラスのインスタンスメソッド内で用いられるものであり、直上スーパークラスのデータ/メソッドにアクセスするための参照である。オーバーライドやドミナンスを無視してスーパクラスのメンバを呼び出すための仕組みである。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;アクセスコントロール
:(''access control'')は、カプセル化の情報隠蔽に基づいた機能であり、クラス内のデータとメソッドの可視性を決定する。可視性とはそれにアクセス(参照/変更)できる範囲を意味する。これにはレキシカルスコープ基準とクライアント基準の二通りがあるが、前者の方が一般的である。広く使われているレキシカルスコープ基準の可視性は、プライベート、プロテクト、パブリックの三種が基本である。プライベートは同クラス内のメンバからのみ、プロテクトは同クラス内と派生クラス内のメンバからのみ、パブリックはどこからでもアクセス可能である。クライアント基準の可視性は、自身メンバへのアクセスを許可するクライアントクラス(フレンドクラス)を定義する方法で決められる。そのクライアントの許可は同時にその派生クラスの許可も兼ねている事が多く、継承によるクラス群の一括定義を可能にする。
-->
<!--
;コピーコンストラクタ
:(''copy constructor'')は、メソッドの引数に対する値インスタンスの値渡しの時に呼び出されるコンストラクタである。値渡しはインスタンス内容全体のメモリコピーであり、基本データ型では特に問題は生じないが、そうでないクラスのインスタンスでは例えばあるリソースへの参照を保持している場合に好ましくない保持重複が発生する事になる。呼び出されたコピーコンストラクタは値インスタンスを受け取り、単純コピーが許されない部分に任意の処理を施して生成した値インスタンスのコピーを引数へと渡す。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;[[オーバーロード]]
:(''overloading'')は、同じメソッド名(返り値の型+メソッド名)にそれぞれ異なるパラメータリスト(引数欄)を付けたものを列挙してメソッドを多重定義する仕組みを指す。[[演算子]]もオーバーロード対象であり、[[単項演算子]]なら一つの引数の型、[[二項演算子]]なら二つの引数の型を多重定義することで演算対象の値の型ごとに計算内容をカスタマイズできる。任意個数の引数を多重定義できる( )演算子は、[[クロージャ]]または[[関数オブジェクト]]の表現に用いられる。
;[[オーバーライド]]
:(''method overriding'')は、基底クラスで定義されたメソッド名義の呼び出しを、派生クラスで実装されたメソッド内容の実行につなげる機能である。これは基底メソッドを派生メソッドで上書きすると形容される。オーバーライドされた基底メソッドの内容はスルーされて派生メソッドの内容が実行される。メソッドシグネチャ(返り値の型+メソッド名+各引数の型と個数)が完全一致している基底側が派生側でオーバーライドされる。オーバーライド指定は、基底側のメソッドをvirtualやabstractで修飾する方式と、派生側のメソッドをoverrideやredefineで修飾する方式がある。前者では基底側でオーバーライド可否の定義が固定されるのに対して、後者では派生側で再定義できる。finalで修飾されたメソッドは再定義不可のオーバーライドの拒絶になる。オーバーライドメソッドの呼び出しは、基底クラスの型に代入された派生クラスのインスタンスで行われる。オーバーライドによって呼び出される内容が多相化されたメソッドは[[仮想関数]]と呼ばれる。[[仮想関数テーブル]](''virtual method table'')はその多相化のための仕組みであり、メソッドシグネチャとメソッド内容アドレスがマッピングされている。
-->
<!--
;ドミナンス
:(''dominance'')は言語によってハイディング(''hiding'')マスキング(''masking'')とも呼ばれる。継承による階層的クラス構造において、サブクラスのメンバがスーパークラスの同名のメンバを隠していることを指す。親クラスのAメソッドを子クラスが同名Aメソッドでドミナンスした場合、子の型で参照しているインスタンスはそこでAのサーチが止まって子Aが呼び出される。ただし親の型で参照すれば親Aを呼び出せる。オーバーライドと異なり、参照する型でインスタンスの振る舞いを変えるための単純な仕組みでもある。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;[[仮想継承]]
:(''virtual inheritance'')は、多重継承での[[菱形継承問題]]を回避するための仕組みである。菱形継承問題とは共にAクラスを親とするBクラスとCクラスの双方を継承した場合に、その継承構造上でAクラスが二つ重なって存在することになる不具合である。仮想継承では専用のテーブルが用意されて、そこでクラス名が参照アドレスにマッピングされる。BクラスからのAクラスと、CクラスからのAクラスは共に同じ参照アドレスをマッピングするのでAクラスはひとつにまとめられる事になる。同時に一度辿ったクラスは省略される事にもなる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;MRO
:メソッド解決順序(''method resolution order'')は、多重継承時の親クラスの巡回順序を定義するものである。参照されたメソッドが自クラスにない場合はその親クラスを巡回してサーチされる。メソッドはクラスメンバと読み替えてもよい。これは[[深さ優先探索|深さ優先検索]](''deep-first'')と[[幅優先探索|幅優先検索]](''breadth-first'')に分かれるが、オブジェクトの構造概念から深さ優先の方が自然とされている。従って一般的な多重継承では深さ優先検索が用いられて親クラスの重複は仮想継承で解決されている。しかし詳細は割愛するが、仮想継承部分の巡回順序に不自然さを指摘する意見もあったので、これを解決するために深さ優先と幅優先をミックスしたC3線形化(''C3 linearization'')というメソッド解決順序が考案された。C3線形化では親クラスの重複部分に対してのみ幅優先検索を適用することで、仮想継承を用いることなく菱形継承問題も自然に解決されている。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->


=== GoF Design Patterns ===
<!--
[[デザインパターン (ソフトウェア)|GoFデザインパターン]]は、ソフトウェア開発における代表的なクラスデザイン問題をピックアップし、それぞれの解決に最適なクラスパターンを提示したものである。1994年から四人の識者([[Gang of Four]])によって発表され、OOPのデザインパターンの代表格と見なされた。教科書の内容としても取り上げやすい形式化されたトピックであったためにオブジェクト指向の学習面では非常に重視された。5個の生成パターン、7個の構造パターン、11個の振る舞いパターンに分類されている。
{{型システム}}
生成に関するパターン<gallery heights="40">
;[[インタフェース (抽象型)|インターフェース]]
:(''interface'')はプログラム概念と機能名の双方を指す用語である。インターフェースは、抽象メソッドのみで構成される純粋抽象クラスを指しているが、言語によっては実体メソッドのメンバも許されている事がある。データはメンバにされないが、定数は許されている事がある。インターフェースはクラスの振る舞い側面を抜き出した抽象オブジェクトと解釈されている。クラスはインターフェースを実装継承し、多重継承可能である。インターフェースは自身を実装継承した[[下位概念]]クラスをグループ化できる。インターフェースは{{仮リンク|記名的型付け|en|Nominal type system|label=}}に準拠しているので実装されたインターフェース名の明記が自身の[[下位概念]]の判別基準にされる。抽象クラスと同様にインスタンス化はできない。言語によってはプロトコルとも呼ばれ、この場合は記名ではなくメンバ構成が自身の[[下位概念]]の判別基準になる{{仮リンク|構造的型付け|en|Structural type system|label=}}の性質を備えたものにされている。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;型イントロスペクション
:''(type introspection'')は一般に実行時型チェックと呼ばれるものである。プログラマが認知できない形で[[コンパイラ]]または[[インタプリタ]]が別途実装している[[インスタンス]]の型情報を、実行時にその都度参照してインスタンスの型を判別する仕組みである。[[静的型付け]]下では専用の実行時型チェック構文(instanceofやdynamic_cast)によって型判別し、ダウンキャストなどに繋げられる。[[動的型付け]]下では変数への代入時や関数への引数適用時にランタイムシステムが自動的に型判別するようなものになる。型イントロスペクションでは型情報のタグ識別子が判定基準になっているので{{仮リンク|記名的型付け|en|Nominal type system|label=}}の考え方に準じている。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[型推論]]
:オブジェクト指向下の型推論''(type inference'')は、型宣言ないし型注釈を省略して定義された変数の「型」が自動的に導き出される機能を指す。型はクラスと同義である。[[静的型付け]]の機能であり、コンパイラ/インタプリタがソースコードをあらかじめ解析し、初期値の代入を始めとしたその変数の扱われ方によって型を導き出す。ここで導き出される「型」とは他の変数への代入可能性や、関数の引数への適用可能性といったあくまで等価性の基準で決められるので、プログラマが人為的な意味付けによる型定義を重視している場合は予期せぬ結果が発生することにもなる。型推論は{{仮リンク|推論的型付け|en|Inferred typing|label=}}とも呼ばれ、普通に型宣言と型注釈を用いる{{仮リンク|明示的型付け|en|Manifest typing|label=}}の対極に位置付けられるが、昨今のオブジェクト指向言語では双方を併用するのが主流になっている。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[リフレクション (情報工学)|リフレクション]]
:(''reflection'')は、メタクラス内容を閲覧/変更する機能であるが、変更できる内容範囲は言語ごとに異なっている。データではデータ型、識別子、可視性が変更対象になる。メソッドではリターン型、識別子、パラメータリスト、可視性、オーバーライド指定が変更対象になる。双方の追加定義と削除もできる事がある。スーパークラスも変更できる事がある。メタクラスの変更はそのまま関連クラスと関連インスタンスに反映される。ただし反映範囲はこれも言語によって異なる。
:また、実行時の文字列(char配列やString)をデータとメソッドの内部識別子として解釈できる機能もリフレクションであり、上述のメタクラス操作よりもこちらの方がよく用いられる。これは実行時の文字列データを用いてのデータ/メソッドへの動的なアクセスを可能にする。
-->
<!--
;[[アノテーション|メタアノテーション]]
:(''metadata annotation'')はクラスに任意の情報を埋め込める機能である。情報とは文字列と数値からなるキーワード、シンボル、テキストである。プログラマが自由な形式で書き込んで随時読み取るものであるが、システムから認識される形式のものもある。実装レベルではメタクラスに書き込まれてリフレクション機能またはその[[糖衣構文]]で読み取ることになる。[[マーカーインタフェース|マーカーインターフェース]]の拡張とも見なされている。メタアノテーションはクラス単位だけでなく、言語によってはインスタンス単位やメソッド単位でも埋め込むことができる。
;メソッド拡張
:(''method extension'')は、クラス定義とは別の場所でそのクラスに対する追加メソッドを定義できる機能である。これは状況に合わせてデータ抽象の表現に幅を持たせることを目的にしている。これには数々の書式があるが代表的なのは、静的メソッドまたは静的関数の第1引数をthis修飾して、その第1引数のクラス(型)に対してその静的メソッドをインスタンスメソッドとして追加するというものである。静的メソッドはそのクラススコープ内の限定拡張にできる。静的関数はネスト関数にしてそのローカルスコープ内の限定拡張にできる。双方はグローバル用途にすることもできる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;動的ディスパッチ
:(''dynamic dispatch'')は、コンパイル時のメソッド名から呼び出されるメソッド内容が実行時に決定される仕組み全般を指す用語である。メソッドに引数を渡しての呼び出しを、オブジェクトにメッセージを発送(ディスパッチ)することになぞらえた事が由来である。発送先は実行時に選択決定されるメソッド内容を指す。メッセージは「[[This (プログラミング)|this参照]]×第1引数×第2引数..」といった[[直積集合]]で考えられているのでシングル、ダブル、マルチプルといった呼称になっている。発送先はthisおよび各引数の派生関係の組み合わせで選択される。thisの派生関係のみ影響しているものは仮想関数と呼ばれるシングルディスパッチになる。それがthisでなく引数ならばただのシングルディスパッチになる。thisまたは各引数の内の2個以上のオブジェクトの派生関係が影響しているものは[[多重ディスパッチ|マルチプルディスパッチ]]になる。その中で特にthisと先頭引数の2個が影響して先頭引数インスタンスの仮想関数がthisを引数にしているVisitor形態のものは[[ダブルディスパッチ]]と呼ばれている。
;[[動的束縛|動的バインディング]]
:(''dynamic binding'')は、識別子が参照するまたは呼び出すオブジェクト、インスタンス、メソッド、データなどのプログラム要素が、コンパイル時ではなく実行時に決められる仕組み全般を指す用語である。識別子はいわゆる変数名や関数名などを指す。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;遅延バインディング
:(''late binding'')は、識別子が参照するオブジェクトをコンパイル時に決める事前バインディング(''early binding'')の対義語であり、この場合は識別子が参照するオブジェクトを実行時に決める動的バインディングと同じ意味で用いられる。また他方では動的バインディングの中で、特に実行コードの動的ローディング機能を通して実装される方を遅延バインディングとする考え方もある。実行コードとは[[ダイナミックリンクライブラリ|DLL]]やクラスライブラリやモジュールなどを指しており、それらが内包するクラスやメソッドを専用の不透明型または動的束縛型に代入する。その呼び出しのための内部識別子はコンパイル時には存在していないことが多いので、実行時の文字列(char配列やString)を内部識別子に解釈するためのリフレクション機能が多用されることになる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[パッケージ (Java)|パッケージ]]
:(''package'')は1個以上のクラスをまとめたものである。多くなったクラスをグループ化するための仕組みである。パッケージの定義は言語ごとに異なるが、[[名前空間]](''namespace'')と同等の機能になっているケースが多い。実装レベルではパッケージ名は自動的にクラス名の接頭辞になってクラス名を差別化し、名前衝突を回避している。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[モジュール]]
:(''module'')は1個以上のクラスをまとめたものである。ここでは[[手続き型プログラミング|手続き型]]や[[構造化プログラミング]]でのそれではなく、OOP言語で扱われているモジュール概念について説明する。ただしその定義は言語間で様々である。上述のパッケージと同等の機能にしている言語もある。ミックスインのために使われる変数と関数のメンバグループをそれにしてトレイトと同等の機能にしている言語もある。また、クラス群の動的ローディングに焦点を当てた[[ソフトウェアコンポーネント]]相当の機能にしている言語もある。この動的ローディングは遅延バインディングと同義になり、実行中プロセスへのクラス群の逐次追加を可能にしている。動的ローディング用途のモジュールでは、内包する基底クラスの詳細を明らかにしつつも、その派生クラスの種類と詳細を明らかにしていないケースが多々あるので、その派生クラスを代入するための動的束縛型は特に不透明型(''opaque type'')と呼ばれる。不透明型はもっぱら型制約と併せて用いられる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[モンキーパッチ]]
:(''monkey patch'')はモジュールやスクリプトファイルなどの動的ローディングを用いて、インタプリタ実行後またはコンパイル後のソースコード内容を変化させる手法である。ソースコードに専用のフィルター処理を記述しておき、その中で任意の箇所を動的ローディングされたモジュール内のクラスや関数や変数で置き換えさせる事で、その時の配置モジュールに合わせた処理内容の変化を起こせる。モジュールを外せば専用のフィルター処理は無効になる。この置き換え(パッチ当て)は遅延バインディング相当である。ソースコードを変えなくてもよいのが条件である。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!-- ;[[ジェネリクス]]
:(''generics'')は、クラスメンバの任意の「型」を総称化したままのクラス定義を可能にし、そのクラスをインスタンス化する各構文箇所で「型」の詳細を決定できるようにしたコンパイル時の静的な機能である。言語によっては[[テンプレート (プログラミング)|テンプレート]](''template'')と呼ばれる。ここでの「型」とはデータの型やメソッドの引数値/返り値/計算値の型を指している。クラス内のそれらを総称化して型変数にし、コンストラクタ呼び出し時の仮型引数に実型引数を適用すると、型変数に実型引数を当てはめたインスタンスが生成される。総称化された型を持つクラスはジェネリッククラスと呼ばれる。特定の型に依存しないクラスを汎用的に定義できるので、型が違うだけの重複コードを削減できるという利点がある。
:言語によっては、ジェネリッククラス同士を[[共変性と反変性 (計算機科学)|共変性と反変性]]による継承関係で結ぶことができる。これはジェネリッククラスに適用する実型引数の継承関係を、そのジェネリッククラス同士の継承関係にシフトする仕組みである。<code>class 猫 extends 動物</code>とすると<code>List<猫></code>は<code>List<動物></code>のサブクラスになる。共変性は実型引数の継承関係をそのままジェネリッククラスの継承関係にシフトするが、反変性ではこれを逆にする。共変性では<code>List<猫></code>は<code>List<動物></code>のサブクラスだが、反変性では<code>List<動物></code>は<code>List<猫></code>のサブクラスになる。[[共変性と反変性 (計算機科学)|共変性と反変性]]はまとめてバリアンス(''variance'')と呼ばれる事がある。
--><!-- 記述の必要性が薄いように思えます -->
<!-- ;型制約
:(''type constraint'')は、(A)ジェネリッククラスの型引数/型変数、(B)代入値の型が実行時に決められる動的束縛型の変数、(C)動的ローディング時に詳細が隠されたままの値が代入される不透明型の変数、などの宣言に用いられるものである。それぞれは制約用の基準クラスで記号修飾され、その基準クラス及びその派生型の値が代入、束縛、適用されるという宣言になる。(A)の型引数/型変数では基準クラス及びその派生クラスが適用される宣言になる。(B)の動的束縛型では基準クラス及びその派生型の値が代入される宣言になる。(C)の不透明型では基準クラス及びその詳細不明である派生型の値が代入される宣言になる。型制約は型境界(''type bound'')とも呼ばれる。これには上限と下限がある。型制約と上限型境界(''upper type bound'')は性質的に同義である。下限型境界(''lower type bound'')は、基準クラス及びその基底型の値が代入、束縛、適用されるという宣言になる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;タイプメンバ
:(''abstract type member'')はジェネリッククラスのメンバ要素であり、ジェネリッククラス同士で型変数の内容をやり取りするための仲介要素である。Aクラスコンストラクタの型引数にBクラスを適用した際に、適切な代入定義が併記されたAクラス内のタイプメンバに、Bクラスがその内部で扱っている総称型もセットで適用できる。連想配列さながらにBクラスがキー的存在になってAクラスのタイプメンバ内容も決定されることから、この仕組みは関連型または連想型(''associated type'')と呼ばれる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[関数オブジェクト]]
:(''function object'')はクラスベースでは、( )[[演算子オーバーロード]]による実装と、[[デリゲート (プログラミング)|デリゲート]]による実装などがある。前者はインスタンスを単に関数名らしく見せるための糖衣構文である。後者のデリゲートは、メソッドシグネチャを型種にした[[関数ポインタ]]型の変数である。デリゲート変数にはインスタンスメソッドへの参照が代入されてそのインスタンス種類による処理の多相を表現できる。プロトタイプベースでは、関数はそのままプロパティ/メソッド(=関数のローカル変数/関数)を自由に付け替えできる(動的バインディング)オブジェクトになる。
--><!-- 記述の必要性が薄いように思えます(言語固有) -->
<!--
;[[コルーチン]]
:オブジェクト指向下の[[イテレータ]]と[[ジェネレータ (プログラミング)|ジェネレータ]]は、コルーチン(''coroutine'')機構に基づいている。通常のサブルーチンがコールする側の復帰アドレスだけをスタックに積むのに対して、コルーチンはコールする側とコールされる側双方の復帰アドレスをスタックに積むというサブルーチン機構である。各要素への作用が記されたオペレータが[[無名関数]]やラムダ式などの形態で[[コンテナ (データ型)|データコンテナ]]に渡されると、各要素をフェッチするデータコンテナと、フェッチされた要素を参照ないし加工するオペレータが交互に[[コールスタック]]を用いて連携動作を繰り返す。イテレータはデータコンテナの各要素にオペレータを適用してその結果値に置き換えていく機能である。ジェネレータは(A)データコンテナを複製してその複製先の各要素にオペレータを適用していくという更新コンテナ生成機能、(B)オペレータがデータコンテナの各要素を選別していき最後に全選別要素を結合したコンテナを生成する機能、(C)オペレータがデータコンテナを走査して各要素の総和値を生成する機能の三種がある。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;[[メッセージ転送|メッセージレシーバー]]
:(''message receiver'')は、メソッド名を文字列で受け取ることができる仕組みであり、インスタンスのデフォルトメソッド(共通窓口メソッド)として備えられるものである。メソッド名の次に引数が渡される。メソッド名文字列はセレクタとも呼ばれる。プログラマはセレクタをレシーバー内で自由に解釈して任意のプロセスに選択分岐できる。通常の<code>instance.method(arg)</code>が、レシーバー機構では<code>instance selector: arg</code>や<code>instance.receiver(method_name, arg)</code>のようになる。受け取ったセレクタによる選択分岐をシステム側が自動化したものがメソッドになった。これの応用形であるメソッドミッシングは、インスタンスに事前定義されていないメソッドが呼び出された時にのみ、取りこぼし用のレシーバーが呼び出されて、文字列化されたメソッド名と引数が渡されるという仕組みである。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;[[イミュータブル|イミュータブル・オブジェクト]]
:(''immutable object'')は、データ不変設定されたクラスのインスタンスを意味する。定数だけを持つインスタンス、不変文字列、不変プリミティブの[[ボックス化|ボックス型]]、収納内容が不変のコレクション(Array、List、Set、Map)などを指す。イミュータブル(不変)はオブジェクトの性質というよりも、それを何のためにどう扱うかというアルゴリズムとデザインパターンの方が要点になる。不変オブジェクトは[[並行計算|並行OOP]]と[[関数型言語|関数型OOP]]で最も重要視される。不変オブジェクトではセッターとミューテイタは禁止され、代わりに元への変更を反映して新たに生成したオブジェクトが返されることになる。コレクションクラスでは要素の追加/削除/変更による結果内容のコレクションが新たに生成されてそれが返り値にされまた引数用途にもなることから、これはファーストクラスコレクションと呼ばれる。なお、不変オブジェクトをコピーした専用の可変オブジェクトを取得したのならば、それへのセッターとミューテイタは許される。これは''copy-on-write''と呼ばれる。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;フォワーディング
:転送(''forwarding'')。委譲先のクラスのメソッドが処理を行わずに、そのまた他のクラスの同名メソッドに引数をそのまま渡して、その返り値をそのまま呼び出し元に渡している場合、冒頭の委譲は転送になる。転送用メソッドではどのクラスに引数をパスするかという選択が行われるので、デリゲーションの多相を表現できる。
--><!-- 記述の必要性が薄いように思えます -->
<!--
;[[派生型|サブタイピング]]
:(''subtyping'')はクラス(型)のあらゆる派生関係および派生構造の実装形式とその働き方を包括したプログラム概念である。サブタイプ多相(''subtype polymorphism'')とも呼ばれる。継承、オーバーライド、コンポジション、ジェネリクス、共変反変バリアンス、不透明型といったものは全てサブタイピングの一側面である。オブジェクト指向でよく使われるものは、振る舞いサブタイピング(''behavioral subtyping'')であり、継承とメソッドオーバーライドの合わせ技である仮想関数がそれに当たる。
-->
<!--
; [[デザインパターン (ソフトウェア)|GOFデザインパターン]]
: (''Gang of Four Design Patterns'')はソフトウェア開発において直面しやすい共通的かつ代表的なデザイン問題をピックアップし、それぞれの解決に最適なクラスパターン図を提示したものである。1994年から四人の計算機科学者ないしソフトウェア技術者たち([[Gang of Four]])によって発表され、OOPのデザインパターンの代表格と見なされた。教科書の内容としても取り上げやすい形式化されたトピックであったためにオブジェクト指向の学習面では非常に重視された。5個の生成パターン、7個の構造パターン、11個の振る舞いパターンに分類されている。
: 生成に関するパターン<gallery heights="40">
ファイル:Abstract Factory UML class diagram.svg|[[Abstract Factory パターン|Abstract factory]]
ファイル:Abstract Factory UML class diagram.svg|[[Abstract Factory パターン|Abstract factory]]
ファイル:Builder UML class diagram.svg|[[Builder パターン|Builder]]
ファイル:Builder UML class diagram.svg|[[Builder パターン|Builder]]
273行目: 105行目:
ファイル:Singleton UML class diagram.svg|[[Singleton パターン|Singleton]]
ファイル:Singleton UML class diagram.svg|[[Singleton パターン|Singleton]]
</gallery>
</gallery>
: 構造に関するパターン<gallery heights="40">
構造に関するパターン<gallery heights="40">
ファイル:Adapter pattern UML diagram.PNG|[[Adapter パターン|Adapter]]
ファイル:Adapter pattern UML diagram.PNG|[[Adapter パターン|Adapter]]
ファイル:Bridge UML class diagram.svg|[[Bridge パターン|Bridge]]
ファイル:Bridge UML class diagram.svg|[[Bridge パターン|Bridge]]
282行目: 114行目:
ファイル:UML DP Proxy.png|[[Proxy パターン|Proxy]]
ファイル:UML DP Proxy.png|[[Proxy パターン|Proxy]]
</gallery>
</gallery>
: 振る舞いに関するパターン<gallery heights="40" perrow="11">
振る舞いに関するパターン<gallery heights="40" perrow="11">
ファイル:Chain of responsibility UML diagram.png|[[Chain of Responsibility パターン|Chain of Responsibility]]
ファイル:Chain of responsibility UML diagram.png|[[Chain of Responsibility パターン|Chain of Responsibility]]
ファイル:Command Design Pattern Class Diagram.png|[[Command パターン|Command]]
ファイル:Command Design Pattern Class Diagram.png|[[Command パターン|Command]]
295行目: 127行目:
ファイル:Visitor UML class diagram.svg|[[Visitor パターン|Visitor]]
ファイル:Visitor UML class diagram.svg|[[Visitor パターン|Visitor]]
</gallery>
</gallery>

-->
=== UML(統一モデリング言語) ===
<!-- ↑独立したページが存在するため関連項目へのリンクとするのが簡潔ではないでしょうか -->

=== GRASP ===

=== SOLID ===
SOLIDは、OOPにおける代表的なクラスの設計原則である。1988年に[[バートランド・メイヤー]]が提唱した(O)と、1994年に[[バーバラ・リスコフ]]が提示した(L)に、ソフトウェア技術者ロバート・マーティンが(S)(I)(D)を加えて2000年に発表されている。
:* (S){{仮リンク|単一責任原則|en|Single-responsibility principle}}は、クラスをただ一つの機能を表現するようにデザインすることを推奨している。
:* (O)[[開放/閉鎖原則|解放閉鎖原則]]は、クラスを抽象クラスと実装クラスに分けてデザインすることを推奨している。抽象クラスの定義内容は変更に閉じられており、実装クラスの処理内容は拡張に開かれていることが由来である。
:* (L)[[リスコフの置換原則]]は、実装クラスはその抽象クラスに対して振る舞い的に等価計算が可能であることを推奨している。抽象側の公開保有メソッドを実装側も全て保有していれば等価となる。ここでの置換(''substitution'')とは抽象クラスの型の変数に実装クラスの型のインスタンスを代入できることを意味している。
:* (I){{仮リンク|インターフェース分離原則|en|Interface segregation principle|label=}}は、一つのクラスから実現される抽象クラスを一つに限定せず、互いに処理内容に影響し合うメソッド群ごとに分離して複数実現することを推奨している。
:* (D)[[依存性逆転の原則|依存性逆転原則]]は、AクラスがBクラスの機能を使用したい場合は、まずBからその抽象クラスをAに向けて実現し、Aはその抽象クラスを通してBの機能を使用することを推奨している。AはBの機能を使用するという意味でその抽象クラスに依存し、Bは自身の機能を提供するという意味でその抽象クラスに依存することになる。ここでの逆転(''inversion'')とは実装から抽象への方向性を意味している。


== 脚注 ==
== 脚注 ==
303行目: 145行目:


== 関連項目 ==
== 関連項目 ==

{{Normdaten}}
{{Normdaten}}
{{プログラミング言語の関連項目}}
{{プログラミング言語の関連項目}}

2021年4月14日 (水) 05:07時点における版

オブジェクト指向プログラミング(オブジェクトしこうプログラミング、: object-oriented programming、略語:OOP)とは、互いに密接な関連性を持つデータ変数またはプロパティ)とコード関数またはメソッド)をひとつにまとめてオブジェクトとし、それぞれ異なる性質と役割を持たせたオブジェクトの様々な定義と、それらオブジェクトを相互に作用させる様々なプロセスの設定を通して、プログラム全体を構築するソフトウェア開発手法である。

オブジェクト指向という用語自体は、計算機科学者アラン・ケイによって生み出されている。1962年公開の言語「Simula」にインスパイアされたケイが咄嗟に口にしたとされるこの造語は、彼が1972年から開発公開を始めた「Smalltalk」の言語設計を説明する中で発信されて1981年頃から知名度を得た。しかしケイが示したオブジェクト指向の要点であるメッセージングの考え方はさほど認知される事はなく、代わりにクラスオブジェクトという仕組みを注目させるだけに留まっている。同時にケイの手から離れたオブジェクト指向は抽象データ型を中心にした解釈へと推移していき、1983年に計算機科学者ビャーネ・ストロヴストルップが公開した「C++」が好評を博したことで、オブジェクト指向に対する世間の理解は「C++」とそのモデルの「Simula 67」のスタイルで定着した。それに基づいてカプセル化継承ポリモーフィズムといった考え方も後年に確立された。

特徴

クラスベースとプロトタイプベース

OOPというパラダイムは、クラスベースプロトタイプベースの二つのサブパラダイムに大別されている。クラスベースの代表格は「C++」「Java」「C#」であり、プロトタイプベースの代表格は「Python」「JavaScript」「Ruby」である。前者はクラスインスタンスの仕組みを中心にしており、後者はメタクラスの仕組みを採用してクラスとインスタンスの境界を曖昧にしている。前者は静的型付けを重視しており、後者は動的型付けを重視している。2000年代以降になるとプロトタイプベースも静的なクラスを重視するようになったのでその純粋な存在感は失われつつある。本節でもクラスベースを基準にして説明する。

クラスとインスタンス

OOPの要点であるクラスとは、端的に言うと変数と関数をひとまとめにしたものであり、手続きを付けたデータ構造体とも解釈される。コンパイル時定義の静的型付けが普通である。クラスに属する変数はデータメンバまたはデータと総称され、言語別にフィールド、プロパティ属性、メンバ変数といった名称になっている。クラスに属する関数はもっぱらメソッド、メンバ関数、メンバ手続きといった名称になっている。これだけの説明だとC言語Visual Basic系などの非OOP言語で使用されるモジュールと、OOP言語のクラスは同じものに見えるが双方の間には明確な違いがあり、モジュールに抽象abstraction)の考え方とその機能を導入したものがクラスである。抽象化のための機能とは後述のカプセル化継承ポリモーフィズムを指している。

クラスはデータとメソッドの構成を定義した型であるので、それを計算対象や代入対象になる値として扱うにはインスタンスに実体化(量化)する必要がある。その用法でのクラスはユーザー定義型と呼ばれる。クラスはインスタンスのひな型であり、インスタンスはクラスを量化したものである。ここでの量化とは、そのクラスに属する変数の値を全て決定してメモリに展開する行為を指す。言語によっては後述の仮想関数テーブルもセットで展開する。インスタンスは別名としてオブジェクトとも呼ばれる。OOPの主役であるオブジェクトの意味と用法は実は曖昧なのが現状であり言語ごとにも違いがある。

オブジェクト指向の三大要素

クラスベースOOPは抽象データ型の思想に準拠しており、その実装スタイルを規定した以下の三項目は、日本では三大要素または三大原則などと呼ばれている。非OOP言語のモジュールに三大要素仕様を加えたものがOOP言語のクラスになる。カプセル化はthis参照の機構とデータ/メソッドの可視性を指定できる機能、継承は自身のスーパークラスを指定できる機能、ポリモーフィズムはオーバーライド仮想関数テーブルを処理できる機能である。

カプセル化

互いに関連するデータとメソッドをまとめてクラスとし、必要なデータとメソッドのみを外部公開し、それ以外をクラス内に隠蔽する機能をカプセル化と呼ぶ。外部公開されたデータとメソッドはクラス外からの直接アクセスが可能である。内部隠蔽されたデータとメソッドはクラス外からアクセスされないことが保証されこれは情報隠蔽と呼ばれる。同クラス所属のメソッドを通してのデータの閲覧と変更はそのデータの抽象化を意味することになりこれはデータ抽象英語版と呼ばれる。この二つがカプセル化の要点である。データ抽象を実装するための仕組みでもあるthis参照については後節で述べられる。データ閲覧用メソッドはゲッター、データ変更用メソッドはセッターと呼ばれる。データとメソッドの外部公開範囲を、無制限・任意クラスグループ・派生クラスグループの三段階に分けて定義する機能はアクセスコントロールと呼ばれる。

継承

既存クラスのデータ/メソッド構成に任意のデータ/メソッド構成を付け足して、既存構成+新規構成の新しいクラスを定義する機能を継承と呼ぶ。その差分プログラミング目的の継承よりも、既存構成に抽象メソッドを置いて新規構成にその実体メソッドを置くというオーバーライド目的の継承の方が要点にされている。新規構成ではなく実装内容を付け足していくための継承である。既存クラスは基底クラス、親クラス、スーパークラスなどと呼ばれ、新しいクラスは派生クラス、子クラス、サブクラスなどと呼ばれる。抽象メソッドを持つクラスは抽象クラスと呼ばれる。継承できるクラスが一つに限られている単一継承を採用している言語と、継承できるクラスの数に制限がない多重継承を採用している言語に分かれている。抽象メソッドのみで構成される純粋抽象クラスの継承は、インターフェースの実装継承英語版と呼ばれて抽象化目的の継承になる。

ポリモーフィズム

異なる種類のクラスに同一の操作インターフェースを持たせる機能をポリモーフィズム(多態性)と呼ぶ。これはクラスの継承関係を利用して、コンパイル時のメソッド名から呼び出されるプロセス内容を実行時に決定するという仕組みを指す。その実装は仮想関数英語版と呼ばれており、クラスベースOOPのポリモーフィズムはイコール仮想関数となっている。仮想関数はスーパークラスの抽象メソッドの呼び出しを、それをオーバーライドしたサブクラスの実体メソッドの呼び出しにつなげる機能である。抽象メソッドとオーバーライド機能については後節で述べる。ポリモーフィスムの要点は、同じメソッド名からその実行時に対応した異なる処理内容を呼び出せるようにすることである。

コンポジションとデリゲーション

コンポジション(合成)とデリゲーション(委譲)は、継承の原型的仕組みであり、別の言い方をすると合成+委譲を最適化した機能が継承である。継承はis-a構造の委譲、合成はhas-a構造の委譲と読み替える事ができる。合成とは、クラスに特定処理の委譲先となる部品クラスを複数持たせた構造であり、合成クラスがデータ/メソッドを要求されて自身が未所持の場合は、対応可能な部品クラスを選択して委譲するという仕組みである。その要求判別と選択過程を自動化したのが継承であり、部品クラスを親クラスに置き換えて暗黙の委譲先にしたものである。しかしその暗黙委譲は実際に参照されるデータ/メソッドの把握を困難にするという欠点も明らかになったので、合成の価値が再認識されるようになった。既存構成に新規構成を付け足していく差分プログラミング目的では、継承よりも合成を用いる方がよいと考えられている。

動的ディスパッチとメッセージパッシング

動的ディスパッチはポリモーフィズムの原型的仕組みであり、継承構造上でのthis参照によるシングルディスパッチを最適化した機能が仮想関数である。動的ディスパッチはコンパイル時のメソッド名から呼び出されるメソッド内容が実行時に決定される仕組み全般を指す用語であり、メソッド名を基軸にして各引数の型によってプロセスが選択分岐される仕組みを意味するシングルディスパッチと多重ディスパッチを包括している。一つの引数の型がプロセス選択に影響するのはシングル、二つ以上なら多重になる。

メッセージパッシングでは、引数の型に加えてメソッド名も実行時に解釈される要素にされておりそれはセレクタと呼ばれる。object selector: paramような書式でオブジェクトの共通窓口となるメッセージレシーバーにセレクタと引数のメッセージが送られる。また、object.call(method_name, param)のような書式でオブジェクトの共通窓口関数をコールするのもメッセージパッシングと呼ばれる。これは遠隔手続きコールオブジェクト要求ブローカーで用いられており分散オブジェクトの標準的なインターフェース機構になっている。関数名(=メソッド名)も実行時に解釈されるという特徴を指してメッセージパッシングと呼ぶ。よく用いられるセレクタ対応プロセスを自動選択化してコンパイル時最適化した仕組みがメソッドになり、これは関数名をコンパイル時決定する関数呼び出しと同類になった。

インターフェース

インターフェースはカプセル化を更に突き詰めた仕組みであり、データ抽象とメソッド抽象と情報隠蔽を合わせて実現する最もOOPらしい機能と言える。インターフェースは抽象メソッドのみで構成されている純粋抽象クラスである。ゲッター、セッター、プロセスになる各抽象メソッドの実装内容は利用者側から隠されて実行時のその都度に決定される。

プロトタイプとオブジェクト

クラスベースのクラスと実体化とインスタンスは、プロトタイプベースではプロトタイプと複製とオブジェクトに置き換わる。プロトタイプとオブジェクトは双方とも、プロパティとメソッドを自由に付け替え可能にされておりこれは動的バインディングとも呼ばれ、そのプロパティとメソッドの構成による型はダックタイピングで判別される。この特徴は同時にポリモーフィズムになる。その用法は関数オブジェクトと変数オブジェクト(値オブジェクト)に大別され、前者のプロパティは二階述語論理、後者のメソッドは高階述語論理の表現体になり、それ自体がメタ視点から抽象化されたオブジェクトにはカプセル化という概念は必要でなくなる。継承では委譲先になる部品オブジェクトの自由な合成が重視されており、その部品はトレイトと呼ばれる事が多くその合成は多重継承と同義になる。前述のコンポジションはhas-a構造であるが、トレイトはis-a構造の合成である。トレイトの実装はもっぱら構造的型付けで判別される。プロトタイプベースは動的な関数型プログラミングに似た性質になっているが、オブジェクトの柔軟な用法に対しての一定の枠組みが必要であるとも考えられて静的なクラス定義が積極的に導入されるようになり、現状では関数型とOOPのハイブリッドのようなパラダイムに落ち着いている。

メッセージング

メッセージングはオブジェクト指向の父であるアラン・ケイが最重視していた源流思想である。これは当時のLISP風プログラミングの変化球と言えるものであり、関数型プログラミングと対比させると分かりやすくなる。関数(写像)を値に適用するという関数型の基本形に対して、メッセージングでは写像をただのシンボル(=セレクタ)にしており、写像を融合させた値(=オブジェクト)にセレクタを送ると、その値専用の写像がセレクタ別に呼び出されるようになっている。写像から計算式を取り除いてただの象徴記号にしたものがセレクタであり、値と写像を融合したものがオブジェクトである。セレクタには引数としてのオブジェクトを続かせられる。セレクタ用法はたらい回し的なデリゲーションに適しているようである。メッセージングベースのOOPは恐らく永遠の途上段階にあるので、このセレクタ構文を用いているか否かが現在に到るまでの類別基準になっている。

歴史

1954年に初の高水準言語FORTRANが登場すると、開発効率の劇的な向上と共にソフトウェア要求度も自然と高まりを見せてプログラム規模の急速な拡大が始まった。それに対応するために肥大化したメインルーチンをサブルーチンに分割する手法と、スパゲティ化したgoto命令制御構造文に置き換える手法が編み出され、これらは1960年に公開された言語「ALGOL60」で形式化された。当時のALGOLはアルゴリズム記述の一つの模範形と見なされたが、それと並行して北欧を中心にした計算機科学者たちはより大局的な観点によるプログラム開発技法の研究を進めていた。

Simulaの開発(1962 - 72)

1962年、ノルウェー計算センターでモンテカルロ法シミュレーションを運用していた計算機科学者クリステン・ニゴールは、ALGOL60を土台にしてProcessと呼ばれるコルーチン機構を加えたプログラミング言語「Simula」を公開し、続けてその拡張にも取り組んだ。ニゴールの同僚で、1963年にSimulaを汎用機UNIVAC系統上で運用できるように実装した計算機科学者オルヨハン・ダールは、Processにローカル変数構造を共有する手続き(サブルーチン)を加えてパッケージ化する言語仕様を考案し、これは一定の変数と手続きをまとめるモジュールと同類の機能になった。程なくしてALGOL60コンパイラに準拠していての限界を悟ったニゴールとダールは、1965年からSimulaを一から再設計するように方針転換した。その過程で彼らは、計算機科学者アントニー・ホーアが考案して1962年のSIMSCRIPT(FORTRAN用のスクリプト)に実装していたRecord Classを参考にしている。Record Classはソースコード水準の抽象表現を、各汎用機に準拠したマシンコード水準の実装符号に落とし込む段階的データ構造のプログラム概念であった。これをモデルにした継承と、その継承構造を利用した仮想手続き(仮想関数)の仕組みも考案され、上述のパッケージ化されたProcess(モジュール)に継承と仮想手続きの両機能を加えたものを「クラス」と定義し、クラスをメモリに展開したものを「オブジェクト」と定義する言語仕様がまとまり、1967年に「Simula67」が初公開された。オブジェクトという用語は、MITの計算機科学者アイバン・サザランドが1963年に開発したSketchpadCADGUIの元祖)の設計内にあるObjectが先例であった。Simula67コンパイラはまずUNIVAC上で運用され、翌年から汎用機バロースB5500などでも稼働されて北欧、ドイツ、ソ連の各研究機関へと広まり、1972年にはIBM汎用機System/360などにも導入されて北米全土にも広まった。その主な用途は物理シミュレーションであった。

influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming.
SketchpadSimulaARPAネットバロースB5000、それと専攻していた生物学と数学に影響されて僕はプログラミングアーキテクチャを思索していた) — Alan Kay

構造化プログラミングの提唱(1969 - 75)

Simulaの普及と前後して1960年代半ばになると、プログラム規模の際限ない肥大化に伴う開発現場の負担増大が顕著になり、いわゆるソフトウェア危機問題が計算機科学分野全般で取り沙汰されるようになった。その解決に取り組んだ計算機科学者エドガー・ダイクストラは、1969年のNATOソフトウェア工学会議で「構造化プログラミング」という論文を発表しトップダウン設計、段階的な抽象化、階層的なモジュール化、共同詳細化(抽象データ構造と抽象ステートメントのjoint)といった構造化手法を提唱した。ダイクストラの言う構造化とは開発効率を高めるための分割統治法を意味していた。なおこの構造化プログラミングは後に曲解されて制御構造文を中心にした解釈の方で世間に広まり定着している。共同詳細化は抽象データ構造を専用ステートメントを通して扱うという概念である。これはSimulaの手続きを通してクラス内の変数にアクセスするという仕組みをモチーフにしていた。段階的な抽象化と階層的なモジュール化は時系列的にも、SIMSCRIPTの段階的データ構造と、Simura67の継承による階層的クラス構造を模倣したものであった。ダイクストラホーアダールの三名は1972年に『構造化プログラミング』と題した共著を上梓していることから互いの研鑽関係が証明されている。その階層的プログラム構造という章の中でダールは、Simulaの目指した設計を更に明らかにした。

I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
(僕は型アンチではないが、全くうんざりしない型システムも知らない、だからまだ動的型付けを好んでいる) — Alan Kay

1974年にMITの計算機科学者バーバラ・リスコフは「抽象データ型」というプログラム概念を提唱し、ダイクストラが提示したモジュールの共同詳細化を、その振る舞いによって意味内容が定義される抽象データという考え方でより明解に形式化した。一方、1970年に構造化言語Pascalを開発していた計算機科学者ニクラウス・ヴィルトは、ダイクストラによる共著出版後の1975年にモジュール化言語Modulaを提示してモジューラプログラミングというパラダイムを生み出している。このようにいささか奇妙ではあるが、Simulaのクラスとオブジェクトというプログラム概念は、巷で言われる構造化からモジュール化へといった進化の流れとは関係なく、しかもその前段階においてさながら彗星のように生まれたパラダイムであった。

Smalltalkとオブジェクト指向の誕生(1972 - 81)

Simula発のProcessとクラスの示した可能性は、パロアルト研究所の計算機科学者アラン・ケイによるオブジェクト重視と「メッセージング」という考え方のヒントになった。ケイはプログラム内のあらゆる要素をオブジェクトとして扱い、オブジェクトはメッセージの送受信でコミュニケーションするという独特のプログラム理論を提唱した。それには関数適用風の書式を用いたオブジェクト同士の多種多様なデリゲーションと、プログラムコードとしても解釈できるデータ列を送信してそれを評価(eval)することで新たなデータを導出できるなどのアイディアが盛り込まれていた。オブジェクトが送るか受け取ったメッセージは任意のタイミングで評価できるので非同期通信や単方向通信をも可能にしていた。この発想の背景にはLISPの影響があった。オブジェクトとメッセージングの構想に基づいて開発された「Smalltalk」はプログラミング言語とGUI運用環境を併せたものとなり、1972年にデータゼネラルNova上での1000行程度のBASICを使った試作(概念実証)を経て、翌1973年に新開発されたゼロックスAlto上で本格稼働された。Smalltalkの設計を説明するためにケイが考案した「オブジェクト指向」という用語はここで初めて発信された。またケイのメッセージング構想はMITの計算機科学者カール・ヒューイットに能動的なプロセス代数を意識させて、1973年発表のアクターモデルのヒントにもなっている。しかしデリゲーションの多用とデータ列が常にコード候補として扱われる処理系は、当時のコンピュータには負荷が大きく実用的な速度を得られないという問題にすぐ直面した。Smalltalk-74(新たに開発されたBitBLTを使った高速描画版Smalltalk-72)からSmalltalk-76の過程で、やむなくメッセージは(多くの場合)関数の動的コールに、メソッドはパターンマッチ処理から単なる関数へ置き換えられるなど構想時の柔軟さが失われるほど最適化された。また、ケイの留保した継承機構も導入されてオブジェクトは抽象データ型の性格も有するようになった。

Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.The big idea is "messaging"...
(Smalltalkはその構文やライブラリやクラスをも関心にしていないという事だけではない。多くの人の関心を小さなアイディアに向かせたことから、僕はオブジェクトという用語を昔作り出したことを残念に思っている。大切なのはメッセージングなんだ。) — Alan Kay

1980年のSmalltalk-80は、元々はメッセージを重視していたケイを自嘲させるほど同期的で双方向的で手続き的なオブジェクト指向へと変貌していた。それでも動的ディスパッチと委譲でオブジェクトを連携させるスタイルは画期的であり、1994年に発表されるデザインパターンの模範にもされている。1981年に当時の著名なマイコン専門誌『BYTE』がSmalltalkとケイ提唱のオブジェクト指向を紹介して世間の注目を集める契機になったが、ケイの思惑に反して技術的関心を集めたのはクラス機構の方であった。オブジェクト指向は知名度を得るのと同時に、Simula発のクラスとそれを理論面から形式化した抽象データ型を中心に解釈されるようになり、それらの考案者がケイの構想とは無関係であったことから、オブジェクト指向の定義はケイの手を離れて独り歩きするようになった。

C++の開発と普及(1979 - 88)

Simulaを研究対象にしていたAT&Tベル研究所の計算機科学者ビャーネ・ストロヴストルップは、1979年からクラス付きC言語の開発に取り組み、1983年に「C++」を公開した。C++で実装されたクラスは、Simula譲りの継承と仮想関数に加えて、レキシカルスコープの概念をクラス構造に応用したアクセスコントロールを備えていた。C++で確立されたアクセスコントロールはカプセル化の元になったがコードスタイル上ほとんどザル化されており、その理由からストロヴストルップ自身もC++は正しくない(not just)オブジェクト指向言語であると明言している。1986年にソフトウェア技術者バートランド・メイヤーが開発した「Eiffel」の方は、正しいオブジェクト指向を標榜してクラスのデータ抽象を遵守させるコードスタイルが導入されていた。クラスメンバ(フィーチャー)は属性、手続き、関数の三種構成で、手続きで属性を変更し関数で属性を参照するという形式に限定されており、これは抽象データ型の振る舞い意味論に沿った実装であった。アクセスコントロールはモジューラプログラミングの情報隠蔽に沿った方式になり、仮想関数機能は延期手続き/関数として実装された。

I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.
(僕はオブジェクト指向という言葉を作ったけど、C++(のような言語)は考えていなかった) — Alan Kay

1986年からACMオブジェクト指向会議(OOPSLA)を年度開催し、そのプログラミング言語セクションでは抽象データ型の流れを汲むクラス・パラダイムが主要テーマにされ、それを標準化するための数々のトピックが議題に上げられている。モジュール性、情報隠蔽、抽象化、再利用性、階層構造、複合構成、実行時多態、動的束縛総称型自動メモリ管理といったものがそうであり、参画した識者たちによる寄稿、出版、講演を通して世間にも広められた。そうした潮流の中でストロヴストルップはデータ抽象の重要性を訴え、リスコフ基底と派生に分けたデータ抽象の階層構造の連結関係について提言した。契約による設計を提唱するメイヤーが1988年に刊行した『オブジェクト指向ソフトウェア構築』は名著とされ、Eiffelを現行の模範形とする声も多く上がった。ただしこれは学術寄りの意見でもあったようで、世間のプログラマの間では厳格なEiffelよりも柔軟で融通の利くC++の人気の方が高まっていた。他方でオブジェクト指向本来の原点であるメッセージ・メタファに忠実であろうとする動きもあり、1984年に開発された「Objective-C」はSmalltalkをモデルにしてそれを平易化した言語であった。そのメッセージレシーバーは静的なメソッド機構優先の動的ディスパッチ機構という方式で実装された。メッセージレシーバの仕組みは遠隔手続き呼出し/オブジェクト要求ブローカーの実装に適していたので分散システムとオブジェクト指向の親和性を認識させることになった。

コンポーネントとネットワーク(1989 - 97)

ネットワーク技術の発展に連れて、データとメソッドの複合体であるオブジェクトの概念は、分散システム構築のための基礎要素としての適性を特に見出される事になり、IBM社アップル社サン社などが1989年に共同設立したOMGは、企業システムネットワーク向け分散オブジェクトプログラミングの標準規格となるCORBAを1991年に公開した。その前年にマイクロソフト社ウェブアプリケーション向けの分散オブジェクト技術となるOLEを発表し、1993年にはCOMと称するソフトウェアコンポーネント仕様へと整備した。このCOMの利用を眼目にしてリリースされた「Visual C++」「Visual Basic」はウェブ時代の新しいプログラミング様式を普及させる先駆になった。この頃に抽象データ型のメソッドを通したデータ抽象、データ隠蔽、アクセスコントロールおよび分散オブジェクトのインターフェース機構によるプログラムの抽象化といった概念は、カプセル化という用語にまとめられるようになった。クラスの継承が最もオブジェクト指向らしい機能と見なされていたのが当時の特徴であった。継承構造を利用した振る舞いサプタイピングは多態性という用語に包括された。こうしていわゆるオブジェクト指向の三大要素がやや漠然と確立されている。1996年にサン社がリリースした「Java」は三大要素が強く意識されたクラスベースであり、その中の分散オブジェクト技術はBeansと呼ばれた。類似の技術としてアップル社もMacOS上でObjective-Cなどから扱えるCocoaを開発している。また、1994年から96年にかけて「Python」「Ruby」「JavaScript」といったオブジェクト指向スクリプト言語がリリースされ、従来のクラスベースに対する新しいプロトタイプベースを定着させている。1994年のGOFデザインパターンの発表と、1997年にOMGが標準モデリング言語として採用したUMLは、オブジェクト指向プログラミングの標準化を促進させた。

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

代表的なオブジェクト指向言語

デザインパターン

契約による設計

GoF Design Patterns

GoFデザインパターンは、ソフトウェア開発における代表的なクラスデザイン問題をピックアップし、それぞれの解決に最適なクラスパターンを提示したものである。1994年から四人の識者(Gang of Four)によって発表され、OOPのデザインパターンの代表格と見なされた。教科書の内容としても取り上げやすい形式化されたトピックであったためにオブジェクト指向の学習面では非常に重視された。5個の生成パターン、7個の構造パターン、11個の振る舞いパターンに分類されている。

生成に関するパターン

構造に関するパターン

振る舞いに関するパターン

UML(統一モデリング言語)

GRASP

SOLID

SOLIDは、OOPにおける代表的なクラスの設計原則である。1988年にバートランド・メイヤーが提唱した(O)と、1994年にバーバラ・リスコフが提示した(L)に、ソフトウェア技術者ロバート・マーティンが(S)(I)(D)を加えて2000年に発表されている。

  • (S)単一責任原則英語版は、クラスをただ一つの機能を表現するようにデザインすることを推奨している。
  • (O)解放閉鎖原則は、クラスを抽象クラスと実装クラスに分けてデザインすることを推奨している。抽象クラスの定義内容は変更に閉じられており、実装クラスの処理内容は拡張に開かれていることが由来である。
  • (L)リスコフの置換原則は、実装クラスはその抽象クラスに対して振る舞い的に等価計算が可能であることを推奨している。抽象側の公開保有メソッドを実装側も全て保有していれば等価となる。ここでの置換(substitution)とは抽象クラスの型の変数に実装クラスの型のインスタンスを代入できることを意味している。
  • (I)インターフェース分離原則英語版は、一つのクラスから実現される抽象クラスを一つに限定せず、互いに処理内容に影響し合うメソッド群ごとに分離して複数実現することを推奨している。
  • (D)依存性逆転原則は、AクラスがBクラスの機能を使用したい場合は、まずBからその抽象クラスをAに向けて実現し、Aはその抽象クラスを通してBの機能を使用することを推奨している。AはBの機能を使用するという意味でその抽象クラスに依存し、Bは自身の機能を提供するという意味でその抽象クラスに依存することになる。ここでの逆転(inversion)とは実装から抽象への方向性を意味している。

脚注

関連項目