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

現行のオブジェクト指向プログラミングは、1974年に計算機科学者[[バーバラ・リスコフ]]らが提唱した[[抽象データ型]]を基礎的な考え方にする方向性で定着している。[[抽象データ型]]のプログラム実装スタイルを具体的に規定したものが1 - 3であり、日本では一般に三大要素と呼ばれている。これに沿った言語仕様を備えたプログラミング言語がオブジェクト指向準拠と判別されている。4は[[アラン・ケイ]]が重視する元祖的なコンセプトであり、オブジェクト指向の源流思想として蛇足ながら紹介を加える。

{{Quotation|''I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.''<br>（さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによって繋がり合う存在、僕はオブジェクトをそう考えている）|Alan Kay}}{{Quotation|''... 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>（銘々のオブジェクトは関連付けられた幾つかの「代数」を持つ、またそれらの系統群も持つかもしれない、それらは極めて有用になるだろう）|Alan Kay}}{{Quotation|''The Japanese have a small word - ma ... The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.''<br>（日本語には「間」という言葉がある・・・成長的なシステムを作る鍵とは内部の特徴と動作がどうあるべきかよりも、それらがどう繋がり合うかをデザインする事なんだ）|Alan Kay}}{{Quotation|''I wanted to get rid of data. ... I realized that the cell/whole-computer metaphor would get rid of data,'' ...<br>（僕はこうデータを取り除きたかった。・・・僕は気付いた、細胞であり全体でもあるコンピュータメタファはデータを除去するであろうと、）|Alan Kay}}{{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}}

<br>（Smalltalkはその構文やライブラリやクラスをも関心にしていないという事だけではない。多くの人の関心を小さなアイディアに向かせたことから、僕はオブジェクトという用語を昔作り出したことを残念に思っている。大切なのはメッセージングなんだ。）|Alan Kay}}1980年のSmalltalk-80は、元々はメッセージを重視していたケイを自嘲させるほど同期的で双方向的で手続き的なオブジェクト指向へと変貌していた。それでも動的ディスパッチと[[委譲]]でオブジェクトを連携させるスタイルは画期的であり、1994年に発表される[[デザインパターン (ソフトウェア)|デザインパターン]]の模範にもされている。1981年に大手当時の著名なマイコン専門誌[[Byte (magazine)|BYTE Magazine]]が、Smalltalkとケイ提唱のオブジェクト指向を紹介して世間の注目を集める契機になったが、ケイの思惑に反して技術的関心を集めたのはクラス機構の方であった。オブジェクト指向は知名度を得るのと同時に、Simula発の[[クラス (コンピュータ)|クラス]]とそれを理論面から形式化した[[抽象データ型]]を中心に解釈されるようになり、それらの考案者がケイの構想とは無関係であったことから、オブジェクト指向の定義はケイの手を離れて独り歩きするようになった。

[[Smalltalk]]のオブジェクト指向は、[[アラン・ケイ]]がその影響を言及していた[[LISP]]コミュニティを逆に感化して、Smalltalkが提示したメタオブジェクトの概念を通したオブジェクト指向とLISP風プログラミングの連携に向けた構想が練られるようになった。LISPの基礎であるアトムとシンボル型に倣う形で、オブジェクトのメンバ変数名とメンバ関数名自体をその都度評価（''eval''）して実行時の内容を導出し、実際の変数参照や関数呼出につなげるというアイディアが生まれた。これは実装面では単に、フレームと呼ばれる動的配列のスロットに変数や関数のポインタを付け替えするという機構にまとめられた。識別子（変数名と関数名）がマッピングされたスロットも増設削減可能であり、原型クラスと継承クラスのポインタも加えられた。このメタオブジェクト設計を導入して1985年に[[MIT人工知能研究所]]の[[LISPマシン]]上で「Flavors」が実装された。LISPの視点から保有スロット識別子の構成による[[動的型付け]]が盛り込まれ、その構成をパーツ化して多重継承させる[[ミックスイン]]という設計が考案され、また実行時の逐次型スロット識別子保有判別に焦点を当てた[[ダックタイピング]]の概念も生まれた。1988年にFlavorsのデザインを[[Common Lisp]]に融合させた「[[CLOS]]」が公開されたが、こちらは関数を中心にして抽象データ型から距離を置いたスタイルになった。Flavorsのデザインは[[パロアルト研究所]]にも回帰され、計算機科学者デビッド・アンガーがSmalltalkの方言として制作する「[[Self]]」を1987年に初回稼働して90年に一般公開した。LISPコミュニティから逆輸入されてSelfに導入されたメタオブジェクト設計は、後に[[プロトタイプベース]]またはインスタンスベースと呼ばれるパラダイムに発展する。同時にそれと、従来の[[クラス (コンピュータ)|クラス]]機構を中心にしたオブジェクト指向言語を区別するための[[クラスベース]]という言葉も生まれた。

ネットワーク技術の発展に連れて、データとメソッドの複合体であるオブジェクトの概念は、[[分散システム]]構築のための基礎要素としての適性を特に見出される事になり、[[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}}

:1962年に公開された[[Simula]]の後継版バージョンであり、[[クラス (コンピュータ)|クラス]]のプログラム概念を導入した最初の言語である。物理モデルを解析するシミュレーション制作用に開発されたもので、クラスをメモリに展開したオブジェクトはその観測対象要素になった。Simulaのクラスは、一つのローカル変数構造と複数のプロシージャをまとめたミニモジュールと言えるものであったが、継承と仮想関数という先進的な設計を備えていた事でオブジェクト指向言語の草分けと見なされるようになった。[[クラスベース]]の源流である。

:[[クラスベース]]のオブジェクト指向と[[関数型プログラミング]]を融合させた言語。[[クラス (コンピュータ)|クラス]]機構と関数型の[[型システム]]に同等の比重が置かれており静的型付け重視である。[[ミックスイン]]相当の[[トレイト]]と[[ジェネリクス]]を連携させた多態性が重視されている。型変数の[[共変性と反変性 (計算機科学)|バリアンス]]、[[共変性と反変性 (計算機科学)|共変と反変]]双方の型境界、抽象タイプメンバ、ジェネリックトレイト、抽象クラスの組み合わせでオブジェクトを様々に[[派生型|派生型付け]]できる。シングルトンオブジェクトの役割が形式化されて従来のクラス静的メンバの新解釈にも用いられている。専用の定義書式により[[イミュータブル]]なオブジェクトが重視されている。上述の派生型付けスタイルとオブジェクト引数の[[逆写像|抽出]]構文とオブジェクトの[[パターンマッチング|パターンマッチング式]]とオブジェクト引数の[[逆写像|抽出]]構文の併用連鎖計算は[[モナド (プログラミング)|モナド]]を彷彿とさせるものであり、[[抽象データ型]]を値として扱う独特の関数型スタイルを表現できる。[[Java仮想マシン]]上で動作するJavaテクノロジ互換言語である。

:オブジェクト指向で言われるメッセージ（''message''）は、複数の方面の考え方が混同されている曖昧な用語になっている。元々はSmalltalkから始まったメッセージ構文ベースのオブジェクト指向の中心機構である。以前はクラスベースの方でもメソッドの呼び出しをメッセージを送るという風に考えることが推奨されていた。メッセージはオブジェクトのコミュニケーション手段と標榜されているが、その忠実な実装内容はそれほど知られていないのが実情である。最も混同されているものに[[アクターモデル]]があるが、そこで言われる非同期性とオブジェクト指向で言われる評価の遅延性は現行の実装スタイルではそれほど共通していない。[[ソフトウェアコンポーネント準拠ソフトウェア工学]]と[[Object Request Broker|オブジェクトリクエストブローカー]]で言われる[[ソフトウェアコンポーネント]]同士の相互通信もメッセージパッシングと呼ばれることが多いが、その仕様と機能は動的ディスパッチに該当するものである。メッセージのオブジェクト指向的運用はメッセージングと名付けられている。具体的な機能例としてはSmalltalk、Objective-C、Selfの[[メッセージ転送|メッセージレシーバー]]と、Rubyのメソッドミッシングなどがあるが、いずれもメッセージングの本質ではないとも言われている。

:（''overloading''）は、一つのメソッド名に複数のそれぞれ異なるパラメータリスト（引数欄）を付けたものを任意の数だけ列挙してメソッド名を多重定義すること仕組みを指す。[[演算子]]もオーバーロード対象であり、[[単項演算子]]なら一つの引数の型、[[二項演算子]]なら二つの引数の型を多重定義することで演算対象の値の型ごとに計算内容をカスタマイズできる。任意個数の引数の型を多重定義できる( )演算子は、[[クロージャ]]または[[関数オブジェクト]]の表現に用いられる。アドホック多相とされる。

:（''C3method linearizationresolution order''）は、多重継承で用いられ時の親クラスの巡回順序を定義する幅優先ものである。参照されたメソッド解決順序（''Method Resolution Order''）であが自クラスにない場合はその親クラスを巡回してサーチされる。メソッドはクラスメンバと読み替えてもよい。自クラス内に無いメンバをこれは[[深さ優先探すための親索|深さ優先検索]]（''deep-first''）と[[幅優先探索|幅優先検索]]（''breadth-first''）に分かれるが、オブジェクラストの順序を決定する仕組みであ構造概念から深さ優先の方が自然とされている。従って一般の的な多重継承では、深さ優先検索によるメソッド解決順序が用いられて親クラスの重複は仮想継承で解決されている。そしかし詳細は割愛するが、仮想継承部分の巡回順序に不自然さを指摘する意見もあったので、これを解決するために対深さ優先と幅優先をミックスしてたC3線形化では、深（''C3 linearization''）というメソッド解決順序が考案さレベルを先行基準にしれた。C3線形化では親クラスの整列と重複部分に対した親クラスのマージが行われて、その結果の親クラス線形化リストはみ幅優先検索にを適用することで、仮想継承を用いることなく菱形継承問題も自然に解決されている。

:（''interface''）はプログラム概念と機能名の双方を指す用語である。言語によってはプロトコルと言われる。抽象メソッドと実メソッドをメンバにできる純粋抽象〜半抽象クラスを意味する。クラスの振る舞い側面を抜き出した抽象体である。クラスによるインターフェースの継承は実装と呼ばれる。多重実装可が普通である。ミックスインとの違いは、抽象階層に焦点が当てられている事であり、直下の実装オブジェクトを共通の振る舞い側面でまとめることがその役割である。インターフェースは自身の[[下位概念]]である実装継承オブジェクトをグループ化できる。{{仮リンク|記名的型付け|en|Nominal type system|label=}}に準拠しているのでインターフェースの実装の明記が振る舞い側面の識別基準になる。インターフェースは抽象メソッド主体なので多重継承時のメンバ名の重複はあまり問題にならない。共通の実装メソッドに集約されるからである。インターフェースは非インスタンス対象である。

:（''mixin''）はインターフェースに似たプログラム概念を指す用語である。機能名は言語によって[[トレイト]]、プロトコル、構造型（''structural type''）と言われる。抽象メソッドと実メソッドとデータメンバをメンバにできる継承専用クラスを意味する。クラスを特徴付けるための構成パーツである。クラスによるトレイトの継承は実装と呼ばれる。多重実装可が普通である。インターフェースとの違いは、トレイトの実装階層に焦点が当てられている事であり、オブジェクトを所有メンバで特定してまとめることがその役割である。トレイトは自身の[[上位集合]]である実装継承オブジェクトをグループ化できる。{{仮リンク|構造的型付け|en|Structural type system|label=}}に準拠しているので所属メンバ構成自体がトレイト等価性の識別基準になる。これはトレイト実装を明記していなくても、そのトレイトが内包する全メンバを所持していれば同じトレイトと見なされることを意味する。トレイトは合成や交差が可能である。トレイトは多重継承時のメンバ名重複の際にその参照の優先順位に注意する必要がある。トレイトは非インスタンス対象である。

:''（duck typing''）は、特定のデータメンバ名またはメソッド名（メソッドシグネチャ）またはプロパティ名（データメンバ名）の識別子を持っているかどうかでインスタンスをその都度分類すること仕組みである。またこれは選その場限り分けるこの型判別と言えるものである。選り分けら判別されたインスタンスはその指名データメンバないし指名自身が持つとされたメソッドでのアクセス対象またはプロパティを呼び出される事になる。動的型付けの機能であり、ダックタイピンスタンス、変数、オブジェクトを実行時に逐次グでは型情報の構成内容が判別すると定基準になっていう点るので{{仮リンク|構造的型推論と区別され付け|en|Structural type system|label=}}の考え方に準じている。

:オブジェクト指向下の型推論''（type inference''）は、型宣言ないし型注釈を省略して定義された変数の「型」が自動的に導き出される機能を指す。型はクラスと同義である。静的型付けの機能であり、コンパイラまたはインタプリタがソースコードをあらかじめ解析しながら、値の代入を始めとしたその変数の扱われ方によって型を導き出す。ここで導き出される「型」とは他の変数への代入可能性や、関数の引数への適用可能性といったあくまで等価性の基準で決められるので、プログラマが人為的な意味付けによる型定義を重視している場合は予期せぬ結果が発生することにもなる。

:（''dynamic dispatch''）は、コンパイル時のメソッド名から呼び出されるメソッド内容が実行時に決定される仕組み全般を指す用語である。メソッドに引数を渡しての呼び出しを、オブジェクトにメッセージを発送（ディスパッチ）することになぞらえた事が由来である。発送先は実行時に選択決定されるメソッド内容を指す。メッセージは「[[This (プログラミング)|this参照]]×第1引数×第2引数..」といった[[直積集合]]で考えられているのでシングル、[[ダブルディスパッチ|ダブル]]、[[多重ディスパッチ|マルチプル]]といった呼称になっている。発送先はthisおよび各引数の派生関係の組み合わせで選択される。thisの派生関係のみ影響しているものは専ら仮想関数なと呼ばれるシングルディスパッチであになる。それがthisでなく引数ならばただのシングルになる。thisとまたは各引数の内の2個以上のオブジェクトの派生関係が影響しているものはダブルないし[[多重ディスパッチ|マルチプルディスパッチ]]になる。その中で特にthisと先頭引数の2個が影響して先頭引数インスタンスの仮想関数がthisを引数にしているVisitor形態のものは[[ダブルディスパッチ]]と呼ばれている。

:（''late binding''）は、識別子が参照するオブジェクトをコンパイル時に決める事前バインディング（''early binding''）の対義語であり、この場合は識別子が参照するオブジェクトを実行時に決める動的バインディングと同じ意味で用いられる。また他方では動的バインディングの中で、特に実行コードの動的ローディング機能を通して実装される方を遅延バインディングとする考え方もある。実行コードとは[[ダイナミックリンクライブラリ|DLL]]やクラスライブラリやモジュールなどを指しており、それらが内包するクラスやメソッドを専用の不透明型または動的束縛型に代入する。その呼び出しのための内部識別子はコンパイル時には存在していないことが多いので、実行時の文字列（char配列やString）を内部識別子に解釈するためのリフレクション機能が多用されることになる。

:オブジェクト指向下の関数オブジェクト（''function object''）は、メソッドそのものをオブジェクトして扱うというプログラム概念である。関数型プログラミングの[[クロージャ]]をモデルにしている。単にインスタンスを単に関数名らしく見せるための糖衣構文である( )[[演算子オーバーロード]]や、メソッドシグネチャを型種にした[[関数ポインタ]]型の変数である[[デリゲート (プログラミング)|デリゲート]]などの実装形式がある。デリゲート変数にはインスタンスメソッドへの参照が代入されてクラス種類とそのインスタンス種類による処理の多相を表現できる。プロトタイプベースにおける関数はオブジェクトそのものと言える存在であり、ローカル変数がプロパティ存在になっているのでクロージャが自然表現できる他、写像の型として解釈されるローカル変数はメソッドの表現手段になる。そのメソッドの引数構成もプロパティ存在になっている場合はそれも変更できてクラスベースにおけるリフレクションを自然表現する。

:* 汎化（''generalization''）は継承による[[is-a]]関係であり、サブクラスからスーパークラスへの連結を指す。

:* 特化（''specialization''）は継承による[[is-a]]関係であり、スーパークラスからサブクラスへの連結を指す。

:* 実装（''realizationimplementation''）はクラスの振る舞いの抽象化による[[is-a]]関係であり、クラスからインターフェースからクラスへの連結を指す。振る舞いとは特定の目的に沿ったメソッド群である。

:* 集約（''compositionaggregation''）は強弱い[[has-a]]関係。であり、AクラスがBクラスをデータメンバにし、Aクラスのコンストラクタと同時には関係なくBインスタンスが生成され、Aクラスのデストラクタと同時にでBインスタンスが破棄されるず、また分離時も破棄されない場合、AはBの合成集約となる。Bが自身のサブAクラスがコレクション（配列、List、Set、Map）の仕組みで交換されるBインスタンスを持つ場合も、Aは分離とBの集約ともに破棄されなる。

:* 依存（''aggregationdependency''）は弱強い[[has-a]]関係。AクラスがBクラスをデータメンバにしであり、Aクラスのコンストラクタとは関係なくBインスタンスいずれかのメソッドが生成され、ABクラスを引数のデストラクタでBインスタンスが破棄されず、型また分離時も破棄されなは返り値の型にしている場合、AはBの集約に依存しているとなる。なお、AクラスがコレBクション（配列、List、Set、Map）ラスの型の仕組みでBインスデータメンスバを持つ[[has-a]]している場合も、のAはからBへの依存は、合成/集約となる。コレクション性を強調する場合は収容（''containment''）とすることもあの方で省略されている。

;[[SOLID|SOLID原則]]

:（''SOLID Principles''）は、汎いわゆる抽象化・特化・実現・実装・関連・依存の関係に焦点を当てたクラスの設計原則である。(S)単一責任原則・(O)解放閉鎖原則・(L)リスコフの置換原則・(I)インターフェース隔分離原則・(D)依存の性逆向き転原則といった五つから成り立っている。1988年に[[バートランド・メイヤー]]が提唱した(O)と、1994年に[[バーバラ・リスコフ]]が提示した(L)に、ソフトウェア技術者ロバート・マーティンが(S)(I)(D)を加えて2000年に発表されている。これはSOLIDの文字通りの順に解釈できるようになっている。

:* (S){{仮リンク|単一責任原則|en|Single-responsibility principle}}は、クラス（属性・操作）をただ一つの機能を表現するようにデザインすることを推奨している。

:* (O)[[開放/閉鎖原則|解放閉鎖原則]]は、クラスを抽象クラス（汎化・実現）と実装クラス（特化・実装）に分けてデザインすることを推奨している。抽象クラスの定義内容は変更に閉じられており、実装クラスの処理内容は拡張に開かれていることが由来である。

:* (L)[[リスコフの置換原則]]は、汎化と特化に対する枠組みであり、実装クラスはその抽象クラスに対して振る舞い的に等価計算が可能であるようにすることを推奨している。抽象側の公開保有メソッドを実装側も全て保有していれば等価となる。ここでの置換（''substitution''）とは抽象クラスの型の変数に実装クラスの型のインスタンスを代入できることを意味している。

:* (I){{仮リンク|インターフェース隔分離原則|en|Interface segregation principle|label=}}は、実現と実装に対する枠組みであり、一つのクラスから実現される抽象クラスを一つに限定せず、互いに処理内容に影響し合うメソッド群ごとに隔分離して複数実現することを推奨している。

:* (D)[[依存性逆転の原則|依存の性逆向き転原則]]は、関連と依存に対する枠組みであり、AクラスからがBクラスに向けて関連線の機能を引き使用したい場合は、まずBからその抽象クラスをAに向けて実現し、Aはその抽象クラスに対を通してAからBの関連線機能を引く使用することを推奨している。AはBからの機能を使用するという意味でその抽象クラスへのに依存線がし、AからBは自身の関連線機能を提供するとは逆向きいう意味でその抽象クラスにな依存することが由来であになる。ここでの依存線逆転（''inversion''）とは実装から抽象クラスへの生成方向性を意味し、関連線はメソッドの呼び出しを意味すている。

ファイル:Singleton UML class diagram.svg|[[Singleton パターン|Singleton]]