オブジェクト指向プログラミング – Wikipedia

Posted on by

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming、略語:OOP）とは、「オブジェクト」という概念に基づいたプログラミングパラダイムの一つである。
オブジェクトは、任意個数のフィールド （属性、プロパティまたは変数）で構成されるデータと、任意個数の（メソッドまたは関数）で構成されるコードのひとまとまりで構成される。

オブジェクトの特徴として、オブジェクト自身の手続きが自身のデータフィールドを読み書きできることが挙げられる(オブジェクトにはthisやselfという概念がある)。また、OOPでは、相互に作用するオブジェクトを組み合わせてプログラムを設計する[1][2]。OOP言語のありかたは多様であるが、最も一般的といえるものは、オブジェクトがクラスのインスタンスであり、また、オブジェクトの型もクラスとして規定されるクラスベースといわれるものである。

広く使われているプログラミング言語の多く（C++、Java、Pythonなど）は、マルチパラダイムであるが、程度の差はあれ、オブジェクト指向プログラミングをサポートしており、大抵は命令型や手続き型プログラミングとの組み合わせで用いられる。
主なオブジェクト指向言語には次のようなものが挙げられる:
Java、C++、C#、Python、R、PHP、Visual Basic .NET、JavaScript、Ruby、Perl、SIMSCRIPT、Object Pascal、Objective-C、Dart、Swift、Scala、Kotlin、Common Lisp、MATLAB、Smalltalk。

UMLによるクラスの表記法。このButtonクラスは、データを表す変数と関数を持ち、継承によりButtonクラスのサブセットとしてサブクラスを作成することが可能である。また、オブジェクトはクラスのインスタンスである。

オブジェクト指向という言葉自体は、計算機科学者アラン・ケイによって考案された[3]が、現在のオブジェクト指向プログラミングという文脈における「オブジェクト」や「指向」を表す用語が初めて登場したのは、1950年代後半から1960年代前半にかけてのマサチューセッツ工科大学(MIT)においてである。
1960年代初頭の人工知能グループ界隈では、「オブジェクト」はプロパティ(属性)を持つ個体識別可能なアイテム(LISPのatom)を意味していた[4][5]。
後にアラン・ケイは、1966年にLISPの内部構造を詳細に理解したことが彼の考え方に強い影響を与えたと述べている。[6]

私は、オブジェクトとは、生物の細胞やネットワーク上の個々のコンピュータのようもの、そしてそれらのコミュニケーションは専らメッセージによって行なわれるもの、と考えていました(つまり、メッセージングは最初から存在していたのですが、プログラミング言語でメッセージングを実用的かつ効率的に行う方法を見つけるまでには時間がかかりました)。

アラン・ケイ, [6]

MITにおける初期の例としては、この他にも、1960年から1961年にかけてアイバン・サザランドが作成したSketchpadが挙げられる。サザランドは、1963年の技術レポートの用語集(Sketchpadに関する自身の博士論文をもとにしたもの)で、グラフィカルなインタラクションに特化しているとはいえ「オブジェクト」と「インスタンス」の概念を定義している(クラスの概念は”master”または”definition”として把握されている)。[7]
また、MIT版のALGOLであるAED-0では、データ構造(この言語の方言では”plexes”と呼称)と手続きを直接結びつけ、後に「メッセージ」、「メソッド」、「メンバ関数」と呼ばれるようなものの萌芽がみられる。[8][9]

1962年、クリステン・ニゴールはノルウェー計算センターでシミュレーション言語のプロジェクトを開始した。これは彼が以前に用いたモンテカルロ法と実世界のシステムを概念化する仕事に基づくものであった。オーレ＝ヨハン・ダールが正式にプロジェクトに参加し、UNIVAC I(UNIVAC 1107)上で動作するSimulaプログラミング言語が設計された。Simulaは、クラスやオブジェクト、継承、ダイナミックバインディングなど、今日のオブジェクト指向プログラミングには不可欠である重要な概念を導入した。[10]
Simulaはまた、プログラミングにおけるデータ保全を考慮して設計されたものでもあった。プログラミングのデータ保全のために参照カウントによる検出プロセスが実装されたのに加え、最終手段としてガベージコレクタがメモリ内の使用されていないオブジェクトを削除するようになっていた。しかし、データオブジェクトの概念は1965年には既に確立されていたものの、プライベート(-)やパブリック(+)といった変数のスコープのレベルによるデータのカプセル化については、アクセスする手続きもまた隠蔽できなければならなかったため、Simulaでは実装されなかった。[11]

初期の段階では、Simulaはプログラミング言語ALGOL 60のための手続きパッケージとされていた。しかし、ALGOLによる制約に不満を感じた研究者たちは、UNIVAC ALGOL 60コンパイラを使用した本格的なプログラミング言語としてSimulaを開発することにした。ダールとニゴールは1965年から1966年にかけてSimulaの普及に尽力し、スウェーデン、ドイツ、ソビエト連邦などでSimulaの使用が増加した。1968年には、バロース B5000上で広く利用されるようになり、後にはURAL-16コンピュータ上にも実装された。1966年、ダールとニゴールはSimulaのコンパイラを書いた。彼らは、SIMSCRIPT（英語版）(自由形式の英語的な汎用シミュレーション言語)を実装に用いて、アントニー・ホーアのレコード・クラス概念を取り入れることに熱心に取り組んだが、彼らは、一般化されたプロセスの概念として、レコード・クラスの属性を保持する層と、接頭辞(prefix)の系列を保持する層の二層構造とする方式に辿り着いた。
接頭辞の系列を通じて、プロセスは先行する定義を参照し、それらの属性を追加することができる。このようにしてSimulaは、クラスとサブクラスの階層を導入し、これらのクラスからオブジェクトを生成することを可能にする方法を導入することとなった。[12]

1972年にはIBM System/360およびIBM System/370のIBMメインフレーム用にSimula 67コンパイラが完成[10]。同年、フランスのCII 10070およびCII Iris 80メインフレーム用のSimula 67コンパイラが無償で提供された。1974年には、Simulaユーザー会は23カ国のメンバーを有するまでになっていた。1975年初頭、DECsystem-10メインフレームファミリー用のSimula 67コンパイラが無償でリリースされ、同年8月までにDECsystem-10のSimula 67コンパイラは28サイトにインストールされた(そのうちの22サイトは北米)。オブジェクト指向のプログラミング言語としてSimulaは、貨物港における船舶と積載貨物の動きを調査・改善するための研究のような、物理モデリング研究に携わる研究者に主に利用されていた[10]。

1970年代、Xerox パロアルト研究所(PARC)において、アラン・ケイ、ダン・インガルス、アデル・ゴールドバーグらによって、プログラミング言語Smalltalkの最初のバージョンが開発された。Smaltalk-72はプログラミング環境を含み、動的型付けであり、当初はコンパイルしてからの実行ではなくインタプリタ実行であった。Smalltalkは、言語レベルでのオブジェクト指向の適用と、グラフィカルな開発環境で注目されたが、Smalltalkが様々なバージョンを経て成長するにつれ、この言語への関心も高まっていった[13]。
SmalltalkはSimula 67で導入されたアイデアの影響を受けてはいるものの、クラスを動的に生成・変更できるなど、完全に動的なシステムとして設計された[14]。

1970年代、SmalltalkはLispコミュニティに影響を与え、Lispコミュニティは、Lispマシンを通じて開発者に紹介されたオブジェクトベースの技術を取り入れた。Lispの様々な拡張機能(LOOPSやFlavorsなどが導入した多重継承やMixin）の試みは、最終的に関数型プログラミングとオブジェクト指向プログラミングを統合し、メタオブジェクト・プロトコルによる拡張を可能にしたCommon Lispのオブジェクト指向システムへとつながった。
1980年代には、メモリ上のオブジェクトをハードウェアでサポートするプロセッサ・アーキテクチャを設計する試みがいくつか行われたが、Intel iAPX 432やLinn Smart、Rekursivなど、いずれも商業的に成功しなかった。

1981年、ゴールドバーグはByte Magazine 8月号のSmalltalk特集号で、Smalltalkとオブジェクト指向プログラミングをより多くの人々に紹介した。1986年、ACMが主催する第一回OOPSLA(Conference on Object-Oriented Programming, Systems, Languages, and Applications)が開催され、予想に反して1,000人が参加した。1980年代半ばには、ITTでSmalltalkを使っていたブラッド・コックス（英語版）によってObjective-Cが開発され、博士論文でSimulaを扱っていたビャーネ・ストロヴストルップよってオブジェクト指向のC++が作られた[13]。1985年には、バートランド・メイヤーもEiffelの最初の設計を行った。ソフトウェアの品質に焦点を当てたEiffelは、純粋なオブジェクト指向プログラミング言語であり、ソフトウェアのライフサイクル全体をサポートする記法をもつ。メイヤーは、ソフトウェア工学とコンピュータサイエンスの少数の重要なアイデアに基づいたEiffelでのソフトウェア開発手法をオブジェクト指向入門（英語版）で解説している。Eiffelでは、メイヤーが開発した信頼性担保の機構である契約プログラミングが、開発手法と言語の双方に不可欠な要素となっている。

1990年代前半から半ばにかけて、オブジェクト指向プログラミングは、その技術をサポートするプログラミング言語が広く普及したことにより、プログラミングパラダイムとして主要なものとなった。その中には、Visual FoxPro 3.0[15][16][17]、C++[18]、Delphi[19]などがある。
その勢力は、オブジェクト指向プログラミング技術に支えられたグラフィカルユーザインタフェースの人気向上と共に高まった。動的なGUIライブラリとOOP言語が密接に連携している例としては、Smalltalkを規範にしたCのオブジェクト指向の動的メッセージング拡張であるObjective-Cで書かれたmacOSのCocoaフレームワークなどが挙げられる。また、OOPツールキットの存在は、イベント駆動型プログラミングの人気を高めることにも繋がった(ただし、この概念はOOPに限定されるものではない)。

チューリッヒ工科大学では、ニクラウス・ヴィルトらが、データ抽象化やモジュール化プログラミングなどの研究を行っていた(ただし、これらは1960年代以前にも一般的に使われてはいた)。 1978年に発表されたModula-2にはこの2つが盛り込まれており、その後に発表されたOberonでは、オブジェクト指向やクラスなどに対する独自のアプローチが盛り込まれている[20]。

オブジェクト指向の機能は、Ada、BASIC、Fortran、Pascal、COBOLなど、既存の多くの言語に追加されていったが、しかし、設計当初にこれらの機能を想定していなかった言語に追加した場合、コードの互換性や保守性には問題が生じることが多かった。

最近では、主としてオブジェクト指向でありながら、手続き型プログラミングの方法論にも対応した言語が数多く登場している。そのような言語としては、PythonやRubyがある。最近の商業的なオブジェクト指向言語で最も重要なものには、サン・マイクロシステムズ社が開発したJavaや、Microsoftの.NETプラットフォーム用に設計されたC#、Visual Basic .NET(VB.NET)が挙げられる。
これら二つのフレームワークは、実装を抽象化することによるOOP使用の利点をそれぞれの方法で示している。VB.NETとC#間では言語間継承をサポートしており、一方の言語で定義されたクラスが他方の言語で定義されたクラスをサブクラス化することができる[21]。

オブジェクト指向プログラミングでは、オブジェクトを使用するが、言語仕様でOOP対応を謳っていても、関連する技術や構造のすべてが言語機能により直接サポートされているわけではない。以下に挙げる特徴は、特に言及されている例外を除いて、クラス指向やオブジェクト指向の傾向が強いとされる言語(あるいはOOPをサポートするマルチパラダイムプログラミング言語)に共通すると考えられるものである。

非OOP言語との共通点

モジュラープログラミングサポートでは、手続きをファイルやモジュールにまとめて整理する機能がある。モジュールは名前空間を持つため、あるモジュールの識別子が、他のモジュールの同名の手続きや変数と衝突することを避けることができる。

クラスとオブジェクト[編集]

オブジェクト指向プログラミング(OOP)をサポートする言語は、コードの再利用と拡張性のために、典型的には、クラスまたはプロトタイプの形で継承を使用する。クラスを使用するものは、主に二つの概念をサポートする。

  • クラス – 与えられた型やクラスのオブジェクトのデータ形式やそれらを利用可能な手続きの定義であり、また、データや手続き(クラスメソッドとも呼ばれる)そのものを含む場合もある。つまり、クラスは、メンバーとなるデータや手続きを含むものである。
  • オブジェクト – クラスのインスタンス

オブジェクトは、現実の世界にあるものを準えることがある。例えば、描画プログラムには、”円”、”四角”、”メニュー”などのオブジェクトがあり、オンラインショッピングシステムでは、”ショッピングカート”、”顧客”、”商品”などのオブジェクトがある[22]。
オブジェクトは、ファイルのオープンを表すオブジェクトや、米国慣用単位からメートル法に変換するサービスを提供するオブジェクトのように、より抽象的なエンティティを表すこともある。

オブジェクト指向プログラミングとは、単なるクラスやオブジェクトではなく、データフィールドやメソッドを含んだオブジェクト(データ構造)を中心としたプログラミングパラダイム全般のことです。クラスを使って、関係のないメソッドをまとめて整理する——これがオブジェクト指向の本質ではないことを理解しましょう。

Junade Ali, Mastering PHP Design Patterns[23]

各々のオブジェクトは、特定のクラスのインスタンスと呼ばれる(例えば、nameフィールドに “Mary”が設定されているオブジェクトは、クラスEmployeeのインスタンスとなる)。OOPの手続きはメソッドと呼ばれ、変数は、フィールド、メンバー、属性、プロパティとも呼ばれる。関連して、以下のような用語がある

  • クラス変数 – クラス全体に属する。変数をクラス全体に唯一ののものとして所有する。
  • インスタンス変数または属性 – 各々のオブジェクトに属する。データはオブジェクトごとに所有する。
  • メンバ変数 – 特定のクラスで定義されるクラス変数とインスタンス変数の両方を指す。
  • クラスメソッド – クラス全体に属する。クラス変数へのアクセスのみ有し、手続き呼び出しからの入力のみ受け付ける。
  • インスタンスメソッド – 各々のオブジェクトに対して、呼び出された特定のオブジェクトのインスタンス変数、入力、およびクラス変数にアクセスできる。

オブジェクトは、複雑な内部構造を持った変数のようにアクセスされるが、多くの言語で実質的にはポインタでありインスタンス(ヒープやスタック内のメモリ上オブジェクト)への参照として機能する。オブジェクトは、内部コードと外部コードを分離を可能とする抽象化の層を提供する。外部のコードは、特定の入力引数の組み合わせで特定のインスタンスメソッドを呼び出したり、インスタンス変数を読み込んだり、インスタンス変数に書き込んだりすることで、オブジェクトを使用することができる。オブジェクトは、コンストラクタと呼ばれるクラス内の特定メソッドを呼び出すことで生成される。プログラムは実行中に、それぞれ独立して操作することが可能な同じクラスのインスタンスを多数作成することができる。これは、同じ手続きを異なるデータセットで簡便に利用する方法となる。

クラスを使用するOOPをクラスベース・プログラミングと呼ぶことがあるが、プロトタイプベース・プログラミングではクラスを使用しないのが一般的である。そのため、オブジェクトとインスタンスという概念の定義はそれぞれで大きく異なるが類似した用語が用いられている。

言語によっては、トレイトやmixinのような概念を用いてクラスやオブジェクトを構成することが可能である。

クラスベース対プロトタイプベース[編集]

クラスベースの言語では、予めクラスが定義され、そのクラスに基づいてオブジェクトがインスタンス化される。例えば、appleとorangeという2つのオブジェクトが、Fruitというクラスからインスタンス化された場合、それらは本質的には果物であり、同じように取り扱えることの保証がされる。

プロトタイプベースの言語では、オブジェクトが主要な実体である。クラスは存在しない。オブジェクトのプロトタイプとは、あるオブジェクトからリンクされている別のオブジェクトに過ぎない。すべてのオブジェクトは一つのプロトタイプリンクを持つ(一つのみ)。新しいオブジェクトは、プロトタイプとして選ばれた既存のオブジェクトに基づいて作成することができる。fruitオブジェクトが存在し、appleとorangeの両方がfruitをプロトタイプとしている場合、2つの異なるオブジェクトappleとorangeを果物と考えることができる。fruit「クラス」という概念は明示的には存在しないが、同じプロトタイプを共有するオブジェクトの同値クラスとしては存在する。プロトタイプの属性やメソッドは、このプロトタイプで定義された同値クラスのすべてのオブジェクトから委譲先とされる。オブジェクト固有の属性やメソッドは、同値クラスの他のオブジェクトに共有されない場合がある。例えば、属性sugar_contentはappleには予期せず存在しない場合がある。プロトタイプで実装できるのは単一継承のみである。

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

メソッドの呼び出しに応じて実行する手続きのコードを選択するのは、外在するコードではなく、オブジェクトの責任である。典型的には、オブジェクトに関連付けられたテーブルから実行時にメソッドを検索するが、この機能は動的ディスパッチとして知られており、抽象データ型(またはモジュール)において、すべてのインスタンスの操作が静的に実装されているのとは対照的である。呼び出しの変化が、呼び出されたオブジェクトの単一の型にのみには依らない場合(つまり複数のオブジェクトがメソッド選択に関与する場合)、多重ディスパッチと呼ばれる。

メソッド呼び出しは、メッセージパッシングとも呼ばれる。これは、メソッド呼び出しを、ディスパッチのためにオブジェクトに渡されるメッセージ(メソッドの名前とその入力引数)として概念化したものである。

カプセル化[編集]

カプセル化とは、オブジェクト指向プログラミングにおいて、データとそのデータを操作する関数を結び付け、両者を外部からの干渉や誤用から守ることである。データのカプセル化は、OOPの重要な概念である情報隠蔽にも通じる。

クラスがメソッドを通じてのみオブジェクトの内部データへのアクセスを許可し、それ以外の呼び出しコードにアクセスを許可しない場合、これはカプセル化として知られる強力な抽象化、または情報隠蔽の形態である。いくつかの言語(Javaなど)では、クラスがアクセス制限を明示的に行うことができる。例えば、内部データであることをprivateというキーワードで指定し、クラス外のコードが使用することを意図したメソッドをpublicというキーワードで指定することができる。また、メソッドはpublic、private、またはprotected(同クラスとそのサブクラスからのアクセスは許可するが、異なるクラスのオブジェクトからのアクセスは許可しない)のように中間のアクセスレベルとすることもできる。また他の言語(Pythonなど)では、アクセス制限は、命名法などの慣例によってのみ強制される(例えば、privateのメソッドはアンダースコアで始まる名前を持つ、など)。カプセル化することで、外部のコードがオブジェクトの内部動作に関与してしまうことを防ぐことができ、リファクタリングを容易にする。例えば、クラスの設計者は、外部のコードは変更することなく、そのクラスのオブジェクト内部のデータ表現を変更することができる(公開されているメソッドの呼び出しが同じように動作する限りにおいて)。また、特定のデータに関連するすべてのコードを同じクラスに配置することで、他のプログラマが理解しやすいように整理することもできる。カプセル化は、疎結合を促進する技術である。

コンポジション、継承、委譲[編集]

オブジェクトは、そのインスタンス変数に他のオブジェクトを含めることができ、これをオブジェクトコンポジションと呼ぶ。例えば、”従業員”クラスのオブジェクトは、”名前”や “役職”といった自身のインスタンス変数に加えて、”住所”クラスのオブジェクトを(直接またはポインタを介して)含むことができる。
オブジェクトコンポジションは、”has-a” の関係を表現するために使用できる。例えば、すべての従業員は住所を持っているので、すべての”従業員”オブジェクトは、”住所”オブジェクトを格納する場所(オブジェクトに直接埋め込まれていることも、ポインターで指定された別の場所に格納されることもある)にアクセスできる。

クラスをサポートする言語は、大抵は継承をサポートしている。継承とは、クラスを「○○は△△である」という関係(“is-a-type-of”)の階層に配置することであるが、例えば、Employee クラスは Person クラスを継承する場合、親クラスで利用できるデータやメソッドは、子クラスでも同じ名前で利用可能である。また、Person クラスは、”first_name” と “last_name” という変数を “make_full_name()” というメソッドで定義した場合、これらの定義はEmployeeクラスでも利用可能である。加えて、Employeeクラスには変数 “position “と “salary “を追加することもできる。この手法では、同じ手続きやデータ定義を簡単に再利用できるだけでなく、現実世界の関係を直感的に反映できる可能性を広げる。開発者は、データベースのテーブルやプログラミングのサブルーチンを扱うのではなく、開発アプリケーションのユーザーがより精通しているドメインのオブジェクトを扱うことができる[24]。

サブクラスはスーパークラスで定義されたメソッドをオーバーライドできる。言語よっては多重継承が可能だが、多重継承ではオーバーライドの解決は複雑になる可能性がある。また、言語によってはmixinを特別にサポートしているものもあるが、多重継承をサポートする言語では、mixinは単にis-a-type-ofの関係を表すことのないクラスの一つである。mixinは典型的には、同一のメソッドを複数のクラスに追加するために使われる。例えば、共通の親クラスを持たないFileReaderクラスとWebPageScraperクラスに、unicode_to_ascii()というメソッドを持つUnicodeConversionMixinクラスを含ませる(mixin)ことにより共通のメソッドを提供することができる。

抽象クラスは、オブジェクトへインスタンス化することはできない。インスタンス化できる他の”具象”クラスが継承するためにのみ存在する。Javaでは、finalキーワードを用いて、クラスがサブクラス化されるのを防止できる。

Composition over inheritanceの方針は、継承の代わりに合成を使ってhas-a関係を実装することを提唱している。例えば、EmployeeクラスはPersonクラスを継承する代わりに、各Employeeオブジェクトの内部にPersonオブジェクトを含めることで、仮にPersonクラスが公開された属性やメソッドを多数持っていても、外部のコードからは隠せるようにする。また、Goのように、継承を全くサポートしていない言語も存在する。

開放/閉鎖原則は、クラスやメソッドは「拡張に対しては開放的であるが、変更に対しては閉鎖的であるべき」という原則を提唱している。

委譲もまた、継承の代わりに利用できる言語機能である。

ポリモーフィズム[編集]

サブタイピング(ポリモーフィズムの一形態)では、呼び出すコードが、サポートされている階層のどのクラスを操作しているのか(親クラスなのかその子孫なのか)という詳細には関知しないことが可能である。一方、継承階層内のオブジェクト間では、同じ操作名でも挙動が異なる場合がある。

例えば、Circle型とSquare型のオブジェクトが、Shapeという共通のクラスから派生している場合、Shapeの各型のDraw関数は、それぞれの描画に必要な機能を実装しているが、呼び出しのコードは、描画されるShapeが特定の型であるかどうかには無関心でいられる。

これもまた、クラス階層からコードを引き離して単純化し、強力な関心の分離を可能にする抽象化の一種である。

オープンな再帰

オープンな再帰[25]をサポートする言語では、オブジェクトのメソッドは同じオブジェクト上の他のメソッドや自分自身を呼び出すことができる。通常はthisやselfと呼ばれる特別な変数やキーワードを使用して呼び出しをするのが一般的であるが、この変数は「遅延結合」であり、あるクラスで定義されたメソッドが、そのサブクラスで後から定義された別のメソッドを呼び出すことができる。

動的言語でのOOP[編集]

ネットワークプロトコルでのOOP[編集]

デザインパターン[編集]

継承とBehavioral subtyping[編集]

継承は意味論的にはis-aの関係を作るため、サブクラスからインスタンス化されたオブジェクトは、スーパークラスからインスタンス化されたオブジェクトの代わりに、常に安全に使用できる、と推測するのは直感的ではあるが、この直観は、ほとんどのOOP言語、特にミュータブルなオブジェクトを許可している言語では誤りである。(ミュータブルなオブジェクトを持つ)OOP言語の型検査器によって強制される部分型付け(部分型多相/サブタイピング多相)では、いかなる状況でも、振る舞いにおける部分型付け(Behavioral subtyping)は保証することはできない。Behavioral subtypingは一般に決定不能であり、プログラム(コンパイラ)では実装できない。クラスやオブジェクトの階層は、文法間違いでは検出できない使い方がされる可能性を考慮に入れて、慎重に設計する必要がある。この問題はリスコフの置換原則としても知られている。

GoFデザインパターン[編集]

オブジェクト指向とデータベース[編集]

OOPと関係データベース管理システム(RDBMS)は、どちらも今日[update]のソフトウェアとして非常に一般的であるが、双方を接続する場合、関係データベースは、オブジェクトを直接格納しないため(ただし、今日ではこれに近しい拡張機能を持つRDBMSも存在する)、この二つの世界を橋渡しすることが一般的な需要として擡頭した。アクセス方法やデータパターンをOOPとRDBとの間で橋渡しする際の問題は、オブジェクト-リレーションのインピーダンスミスマッチと呼ばれている。
この問題に対処するためのアプローチはいくつかある。欠点のない一般的な解決策といえるものはない[26]が、代表的なものとして、オブジェクト関係マッピング(ORM)があり、Visual FoxProなどのIDE言語や、Java Data Objects、Ruby on RailsのActive Recordなどのライブラリが存在する。

また、RDBMSを代替するオブジェクトデータベースも存在するが、技術的にも商業的にもRDBMSほど広く成功は収めていない。

実世界のモデリング、リレーションシップ[編集]

OOPと制御構造[編集]

OOPは、ソースコードのコードの再利用性やソフトウェアの保守性を高めるよう発展してきたが[27] 、ある時期までは制御フローの透過的な表現については、あまり省みられることもなく、コンパイラが任意に処理すれば良いと考えられてきた。しかし、OOPでの実現にはある種の困難を伴うものの、並列ハードウェアやマルチスレッドコーディングの重要性が増すにつれ透過的な制御フローの開発は重要になってきている[28][29][30][31]。

責任駆動設計 対 データ駆動設計[編集]

責任駆動設計では、クラスは、共有する情報とそれを扱う責務という観点から定義されるべきであるとし、クラス定義(とその利用者)の契約として設計する。Wirfs-BrockとWilkersonは、責任駆動設計と対比して、データ駆動設計は、クラスが保持すべきデータ構造のみを中心に定義されるとし、責任駆動型の設計が望ましいとしている[32]。

SOLID、GRASPのガイドライン[編集]

SOLIDのガイドラインは、プログラミングにおける五つの実践の頭文字をとった語呂合わせであり、マイケル・C・フェザーズ[33]が考案し提唱したものである

GRASP(General Responsibility Assignment Software Patterns）は、クレーグ・ラーマンが提唱したもう一つガイドラインである。

形式意味論[編集]

関連記事[編集]

システム[編集]

モデリング言語[編集]

  1. ^ Kindler, E.; Krivy, I. (2011). Object-Oriented Simulation of systems with sophisticated control. International Journal of General Systems. pp. 313–343. 
  2. ^ Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6th ed. Pearson Education Inc.. ISBN 978-0-321-53205-3 , section 1.6 “Object-Oriented Programming”
  3. ^ “At Utah sometime after Nov 66 when, 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. It was probably in 1967 when someone asked me what I was doing, and I said: “It’s object-oriented programming”.”[1]
  4. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D. et al. (March 1960). LISP I Programmers Manual. en:Boston, en:Massachusetts: Artificial Intelligence Group, en:M.I.T. Computation Center and Research Laboratory. p. 88f. オリジナルの17 July 2010時点におけるアーカイブ。. https://web.archive.org/web/20100717111134/http://history.siam.org/sup/Fox_1960_LISP.pdf. “In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as “property lists”, and atomic symbols are sometimes called “objects”.” 
  5. ^ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Programmer’s Manual. en:MIT Press. p. 105. ISBN 978-0-262-13011-0. https://archive.org/details/lisp15programmer00john/page/105. “Object — a synonym for atomic symbol” 
  6. ^ a b “Dr. Alan Kay on the Meaning of “Object-Oriented Programming”” (2003年). 2010年2月11日閲覧。
  7. ^ Sutherland, I. E. (1963年1月30日). “Sketchpad: A Man-Machine Graphical Communication System”. Technical Report No. 296, Lincoln Laboratory, Massachusetts Institute of Technology via Defense Technical Information Center (stinet.dtic.mil). 2019年7月17日閲覧。
  8. ^
    The Development of the Simula Languages,
    en:Kristen Nygaard, en:Ole-Johan Dahl,
    p.254
    Uni-kl.ac.at
  9. ^
    Ross, Doug. “The first software engineering language”. LCS/AI Lab Timeline. MIT Computer Science and Artificial Intelligence Laboratory. 2010年5月13日閲覧。
  10. ^ a b c Holmevik, Jan Rune (1994). “Compiling Simula: A historical study of technological genesis”. IEEE Annals of the History of Computing 16 (4): 25–37. doi:10.1109/85.329756. オリジナルの30 August 2017時点におけるアーカイブ。. https://web.archive.org/web/20170830065454/http://www.idi.ntnu.no/grupper/su/publ/simula/holmevik-simula-ieeeannals94.pdf 2018年3月3日閲覧。. 
  11. ^ Dahl, Ole Johan (2004). “The Birth of Object Orientation: The Simula Languages”. From Object-Orientation to Formal Methods. Lecture Notes in Computer Science. 2635. pp. 15–25. doi:10.1007/978-3-540-39993-3_3. ISBN 978-3-540-21366-6. http://www.mn.uio.no/ifi/english/about/ole-johan-dahl/bibliography/the-birth-of-object-orientation-the-simula-languages.pdf 2021年10月22日閲覧。. 
  12. ^ Nygaard, Kristen (1978). “The Development of the SIMULA Languages”. ACM SIGPLAN Notices 13 (8): 245–272. doi:10.1145/960118.808391. https://doi.org/10.1145/960118.808391 2021年10月22日閲覧。. 
  13. ^ a b Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. pp. 329. Bibcode: 2009tclp.book…..M. ISBN 978-3-540-92144-8 
  14. ^ Kay, Alan. “The Early History of Smalltalk”. 2007年9月13日閲覧。
  15. ^ 1995年6月 Visual FoxPro 3.0, FoxPro は手続き型言語からオブジェクト指向言語へと進化した。Visual FoxPro 3.0では、データベースコンテナ、シームレスなクライアント/サーバー機能、ActiveXのサポート、OLEオートメーションとヌルのサポートが導入された。Summary of Fox releases
  16. ^ FoxProの歴史: Foxprohistory.org
  17. ^ 1995年のVisual FoxPro 3.0 レビュー/ガイド: DFpug.de
  18. ^ Khurana, Rohit (1 November 2009). Object Oriented Programming with C++, 1E. ISBN 978-81-259-2532-3. https://books.google.com/books?id=MHmqfSBTXsAC&pg=PA16 
  19. ^ マイナビTECH+: Delphiがトップ20位から脱落: 「Delphiは2001年6月にトップ20位入りを果たし、2000年代初頭には最も人気のある統合開発環境として広く使用されていた。」[2]
  20. ^ Wirth, Niklaus. From Modula to Oberon and the programming language Oberon (Report). ETH Technical Reports D-INFK. Band 82. Wiley. https://doi.org/10.3929/ethz-a-005363226. 
  21. ^ 共通型システム|Microsoft Docs [3]
  22. ^ Booch, Grady (1986). Software Engineering with Ada. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. https://en.wikiquote.org/wiki/Grady_Booch. “Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.” 
  23. ^ Ali, Junade (28 September 2016) (英語). Mastering PHP Design Patterns | PACKT Books (1 ed.). Birmingham, England, UK: Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. https://www.packtpub.com/application-development/mastering-php-design-patterns 
  24. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering. Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0. https://archive.org/details/objectorientedso00jaco/page/43 
  25. ^ 『型システム入門』オーム社、2013年、185頁。 18.10 selfを介したオープンな再帰
  26. ^ Neward, Ted (2006年6月26日). “The Vietnam of Computer Science”. Interoperability Happens. 2010年6月2日閲覧。
  27. ^ Ambler, Scott (1998年1月1日). “A Realistic Look at Object-Oriented Reuse”. drdobbs.com. 2010年7月4日閲覧。
  28. ^ Shelly, Asaf (2008年8月22日). “Flaws of Object Oriented Modeling”. Intel Software Network. 2010年7月4日閲覧。
  29. ^ James, Justin (2007年10月1日). “Multithreading is a verb not a noun”. techrepublic.com. 2010年7月4日閲覧。
  30. ^ Shelly, Asaf (2008年8月22日). “HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions”. support.microsoft.com. 2010年7月4日閲覧。
  31. ^ Robert Harper (2011年4月17日). “Some thoughts on teaching FP”. Existential Type Blog. 2011年12月5日閲覧。
  32. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). “Object-Oriented Design: A Responsibility-Driven Approach”. ACM SIGPLAN Notices 24 (10): 74. doi:10.1145/74878.74885. 
  33. ^ https://wiki.c2.com/?MichaelFeathers

関連項目[編集]

外部リンク[編集]