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

オブジェクト指向プログラミング（OOP）は、オブジェクト[1]（データと関数をカプセル化するソフトウェアエンティティ）に基づいたプログラミングパラダイムです。OOPコンピュータプログラムは、相互に相互作用するオブジェクトで構成されます。[2] [3] OOP機能を提供するプログラミング言語はOOP言語に分類されますが、OOPに貢献する機能のセットが議論されているため、言語をOOPとして分類すること、および言語がOOPをサポートする程度、またはOOPである程度は議論の余地があります。パラダイムは相互に排他的ではないため、言語はマルチパラダイムになる可能性があり、OOP以外のものに分類されることもあります。

オブジェクトは、現実世界の物やプロセスをデジタル形式で表現する場合があります。[4]たとえば、グラフィックスプログラムには、、、などのオブジェクトが含まれる場合がありますcircle。squareオンラインmenuショッピングシステムにはshopping cart、、、、customerなどのオブジェクトが含まれる場合がありますproduct。ニクラウス・ヴィルトは、「このパラダイム[OOP]は現実世界のシステムの構造を密接に反映しているため、複雑な動作をする複雑なシステムをモデル化するのに適しています」と述べています。[5]

しかし、多くの場合、オブジェクトは開いているファイルや単位変換器のような抽象的な実体を表します。OOPによって現実世界を正確にコピーすることが容易になる、あるいはそれが必要だという考えに、誰もが賛同するわけではありません。ボブ・マーティンは、クラスはソフトウェアであるため、クラスの関係はそれらが表す現実世界の関係とは一致しないと主張しています。[6] バートランド・マイヤーは、プログラムは世界のモデルではなく、世界の一部のモデルであると主張しています。「現実は二度離れたいとこ同士である」と。[7] スティーブ・イェッゲは、自然言語には関数型プログラミングのように、動作（メソッド）の前に物（オブジェクト）に名前を付けるというOOPのアプローチが欠けていると指摘しました。[8]このため、OOPソリューションは手続き型プログラミングで書かれたソリューションよりも複雑になる可能性があります。[9]

OOPをサポートする注目すべき言語には、Ada、ActionScript、C++、Common Lisp、C#、Dart、Eiffel、Fortran 2003、Haxe、Java、[10] JavaScript、Kotlin、Logo、MATLAB、Objective-C、Object Pascal、Perl、PHP、Python、R、Raku、Ruby、Scala、SIMSCRIPT、Simula、Smalltalk、Swift 、 Vala、Visual Basic (.NET)などがあります。

歴史

プログラミングにおける「オブジェクト」という概念は、1950年代後半から1960年代初頭にかけて、マサチューセッツ工科大学（MIT）の人工知能グループによって提唱されました。ここで「オブジェクト」とは、特定のプロパティ（属性）を持つLISPのアトムを指していました。 [11] [12] もう一つの初期の例として、 1960年から1961年にかけてMITでIvan Sutherlandが作成したSketchpadが挙げられます。Sutherlandは技術報告書の用語集で、「オブジェクト」や「インスタンス」（クラス概念は「マスター」または「定義」でカバー）といった用語を定義しましたが、これはグラフィカルなインタラクションに特化されていました。[13]その後、1968年には、MIT版ALGOLプログラミング言語であるAED-0が、データ構造（「プレックス」）とプロシージャを結び付け、後に「メッセージ」、「メソッド」、「メンバー関数」と呼ばれるようになるものの先駆けとなりました。[14] [15]データ抽象化やモジュラープログラミング といった話題は、当時よく議論されていました。

一方、ノルウェーでは1961年から1967年にかけてSimulaが開発されました。 [14] Simulaは、クラス、継承、動的バインディングといったオブジェクト指向の基本的な考え方を導入しました。[16] Simulaは主に、貨物港を通る船舶とその内容物の動きのような物理モデリング に携わる研究者によって使用されました。 [16] Simulaは、オブジェクト指向言語の主要な機能とフレームワークを備えた最初の言語として一般的に認められています。[17]

私は、オブジェクトを生物細胞やネットワーク上の個々のコンピューターのように、メッセージでのみ通信できると考えていました（つまり、メッセージングは​​ごく初期に登場しました。プログラミング言語でメッセージングを効率的に行う方法を理解するには、しばらく時間がかかりました）。

アラン・ケイ[1]

MITとSimulaの両方の影響を受け、アラン・ケイは1966年11月に独自のアイデアの開発に着手しました。彼は後に、影響力のあるOOP言語であるSmalltalkを開発しました。1967年には、ケイはすでに「オブジェクト指向プログラミング」という用語を会話の中で使用していました。[1] OOPの「父」と呼ばれることもありますが、[18]ケイは自身のアイデアはOOPの一般的な理解とは異なると述べており、コンピュータサイエンス界は彼の概念を採用しなかったことを示唆しています。[1]バーバラ・リスコフ が共著した1976年のMITのメモには、Simula 67、CLU、Alphardがオブジェクト指向言語として挙げられていますが、Smalltalkについては言及されていません。 [19]

1970年代、Smalltalkプログラミング言語の最初のバージョンは、ゼロックスPARCでアラン・ケイ、ダン・インガルス、アデル・ゴールドバーグによって開発されました。Smalltalk-72は、言語レベルでのオブジェクトの使用とグラフィカルな開発環境で注目されました。[20] Smalltalkは完全に動的なシステムであり、ユーザーは作業中にクラスを作成および変更することができました。[21] OOPの理論の多くは、例えば多重継承など、Smalltalkの文脈で開発されました。[22]

1970年代後半から1980年代にかけて、OOPが注目を集めました。Flavorsオブジェクト指向Lispは1979年から開発され、多重継承とミックスインを導入しました。[23] 1981年8月、Byte MagazineはSmalltalkとOOPを特集し、これらのアイデアを幅広い読者に紹介しました[24] Interlisp -DのオブジェクトシステムであるLOOPSはSmalltalkとFlavorsの影響を受けており、1982年に論文が発表されました。[25] 1986年、オブジェクト指向プログラミング、システム、言語、アプリケーションに関する最初の会議（OOPSLA）には1,000人が参加しました。この会議は、Lispオブジェクトシステムを統合する取り組みの始まりを示し、最終的にCommon Lisp Object Systemにつながりました。1980年代には、メモリ内のオブジェクトのハードウェアサポートを含むプロセッサアーキテクチャを設計する試みがいくつかありましたが、これらは成功しませんでした。例としては、Intel iAPX 432とLinn Smart Rekursivがあります。

1980年代半ばには、Objective-C、C++、Eiffelといった新しいオブジェクト指向言語が登場しました。Objective-Cは、 ITT社でSmalltalkを使用していたBrad Coxによって開発されました。Bjarne Stroustrupは、博士論文でSimulaを使用した経験に基づいてC++を作成しました。 [20] Bertrand Meyerは1985年にEiffel言語の最初の設計を行いました。これは、契約による設計アプローチを用いてソフトウェアの品質に重点を置いたものでした。[26]

1990年代には、OOPがプログラミングの主流となり、特にVisual FoxPro 3.0、[27] [28] C++、[29] Delphi [要出典]などがサポートされるようになりました。OOPは、ボタン、メニュー、その他の要素にオブジェクトを使用するグラフィカルユーザーインターフェースの台頭により、さらに普及しました。よく知られている例としては、 macOSで使用され、 Objective-Cで記述されたAppleのCocoaフレームワークがあります。OOPツールキットは、イベント駆動型プログラミングの人気も高めました。[要出典]

ETHチューリッヒでは、ニクラウス・ヴィルトと彼の同僚たちがOOPへの新しいアプローチを生み出しました。Modula -2（1978年）とOberon（1987年）には、モジュール境界を越えたオブジェクト指向、クラス、型チェックへの独自のアプローチが含まれていました。ヴィルトの設計では、継承は明確ではありません。彼の命名法は逆方向を指しているためです。継承は型拡張と呼ばれ、視点は親から継承者へと下がっています。

OOPが普及する前に開発された多くのプログラミング言語は、 Ada、BASIC、Fortran、Pascal、COBOLなど、オブジェクト指向機能が追加されています。

機能

言語によって提供されるOOP機能はさまざまです。以下は、OOP言語の一般的な機能です。[30] [31] [32] [33] OOPをリレーショナルプログラミングなどの他のスタイルと比較することは、OOPの明確で合意された定義がないため困難です。[34]

カプセル化

オブジェクトはフィールドとメソッドをカプセル化します 。フィールド（属性またはプロパティとも呼ばれます）は、情報（状態とも呼ばれます）を変数として保持します。メソッド（関数またはアクションとも呼ばれます）は、ロジックコードを介して動作を定義します。カプセル化とは、関連するコードをまとめることです。

情報の隠蔽

情報の隠蔽とは、コードを必要とするコードだけがアクセスできるようにコードを整理することです。コードベースの残りの部分からはアクセスできません。オブジェクトの内部詳細は外部のコードから隠されているため、オブジェクトのインターフェースや他のコードに影響を与えることなく、オブジェクトの動作を変更できます。情報を隠蔽することで、コードを変更する際の問題を防ぐことができます。[35]オブジェクトは、内部の動作と外部の消費コードとの間の障壁として機能します。消費コードは、オブジェクトのパブリックメンバーを介してのみオブジェクトと対話できます

Javaのような一部のプログラミング言語は、可視性キーワード（privateとpublic）を介して情報の隠蔽を提供します。[36]可視性機能を提供しない言語もありますが、開発者はプライベートメンバー名をアンダースコアで始めるなどの規則に従う場合があります。Javaのprotectedキーワード（同じクラスとそのサブクラスからのアクセスは許可しますが、異なるクラスのオブジェクトからのアクセスは許可しません）や、internalC#、Swift、Kotlinのキーワード（同じモジュール内のファイルへのアクセスを制限します）など、中間レベルのアクセスも存在します。[37]

情報の隠蔽とデータ抽象化の支持者は、コードの再利用を容易にし、現実世界の状況を直感的に表現できると主張しています。[38] [39]しかし、OOPは可読性やモジュール性を向上させないと主張する人もいます。[40] [41] Eric S. Raymondは、 OOP言語は透明性を損なう階層化されたプログラムを奨励する傾向があると書いています。[42 ] Raymondはこれを、 UnixやC言語で採用されているアプローチと比較して不利な点があるとしています。 [42]

SOLIDにはオープン/クローズ原則が含まれており、クラスと関数は「拡張に対してはオープンであるべきであるが、変更に対してはクローズであるべき」とされています。ルカ・カルデッリは、OOP言語は「クラスの拡張と変更に関してモジュール性が非常に乏しい」ため、非常に複雑になりがちであると述べています。[40]後者の点は、 Erlangの主要な発明者であるジョー・アームストロングによって繰り返されており、次のように引用されています。[41]

オブジェクト指向言語の問題は、暗黙の環境を持ち歩いていることです。バナナが欲しかったのに、手に入れたのはバナナとジャングル全体を持ったゴリラでした。

レオ・ブロディは、情報の隠蔽はコードの重複につながる可能性があると述べています[43] 。これはソフトウェア開発の「同じことを繰り返さない」ルール[44]に反します。

合成

オブジェクト合成により、オブジェクトは他のオブジェクトを含むことができます。例えば、オブジェクトはオブジェクトと、やなどの他の情報をEmployee含む場合があります。合成とは、「従業員は住所を持っている」といった「has-a」関係です。 Addressnameposition

継承

継承はクラスまたはプロトタイプを介してサポートできます。これらは異なりますが、オブジェクトやインスタンスなどの類似した用語を使用します。

クラスベース

OOPの最も一般的なタイプであるクラスベースプログラミングでは、オブジェクトはクラスのインスタンスです。クラスはデータ（変数）とメソッド（ロジック）を定義します。オブジェクトはコンストラクターによって作成されます。クラスの要素には以下が含まれます。

  • クラス変数- クラス自体に属し、クラスのすべてのオブジェクトが1つのコピーを共有します。
  • インスタンス変数- オブジェクトに属し、すべてのオブジェクトがこれらの変数の独自のバージョンを持ちます。
  • メンバ変数- クラスのクラス変数とインスタンス変数の両方を参照します。
  • クラスメソッド - クラス変数のみを使用できます。
  • インスタンスメソッド - オブジェクトに属し、インスタンス変数とクラス変数の両方を使用できます

クラスは他のクラスを継承し、クラスの階層構造を形成することがあります。これは、サブクラスがスーパークラスから継承する場合です。たとえば、クラスはEmployeeオブジェクトに変数を付与するクラスEmployeeから継承する場合があります。サブクラスは、スーパークラスに影響を与えない変数やメソッドを追加できます。ほとんどの言語では、サブクラスがスーパークラスのメソッドをオーバーライドすることもできます。一部の言語では多重継承をサポートしており、クラスは複数のクラスから継承できます。また、他の言語では同様にミックスインやトレイトをサポートしています。たとえば、UnicodeConversionMixinというミックスインは、FileReaderクラスとWebPageScraperクラスの両方にメソッドunicode_to_ascii()を追加する場合があります。 PersonPerson

抽象クラスはオブジェクトとして直接インスタンス化することはできません。スーパークラスとしてのみ使用されます。

その他のクラスは、クラス変数とメソッドのみを含み、インスタンス化やサブクラス化を意図していないユーティリティクラスです。[45]

プロトタイプベース

プロトタイプベースプログラミングでは、クラスの概念を提供する代わりに、オブジェクトはプロトタイプまたは親と呼ばれる別のオブジェクトにリンクされます。Selfでは、オブジェクトは複数の親を持つことも、親を持たないこともありますが[46]、最も一般的なプロトタイプベース言語であるJavaScriptでは、オブジェクトはプロトタイプがnullであるベースオブジェクトまでのプロトタイプリンクを1つだけ持ちます。

プロトタイプは新しいオブジェクトのモデルとして機能します。たとえば、オブジェクトがある場合、プロトタイプの特性を共有する2つのオブジェクトとfruitを作成できます。プロトタイプベース言語では、オブジェクトが独自のプロパティを持つこともできるため、オブジェクトは属性を持つことができますが、オブジェクトやオブジェクトは属性を持ちません。 appleorangefruitapplesugar_contentorangefruit

継承なし

Goのような一部の言語は継承をサポートしていません。[47]代わりに、オブジェクトは親子関係ではなく小さな部分を使用して構築される「継承よりも構成」を推奨しています。たとえば、EmployeeクラスはPersonクラスを継承する代わりに、Personオブジェクトを単に含むことができます。これにより、EmployeeクラスはPersonをプログラムの他の部分にどの程度公開するかを制御できます。委譲は、継承の代替として使用できるもう1つの言語機能です。

プログラマーは継承についてさまざまな意見を持っています。C++の作者であるBjarne Stroustrupは、継承なしでOOPを行うことが可能であると述べています。[48] Rob Pikeは、継承がより単純な解決策ではなく複雑な階層を作成するとして批判しています。[49]

継承と振る舞いのサブタイピング

あるクラスが別のクラスを継承する場合、サブクラスは元のクラスのより具体的なバージョンであると考える人がよくいます。これは、サブクラスのオブジェクトは常に元のクラスのオブジェクトを問題なく置き換えることができるというプログラムセマンティクスを前提としています。 この概念は、振る舞いサブタイピング、より具体的にはリスコフの置換原則として知られています

しかし、これは多くの場合当てはまりません。特に、作成後に変化する可変オブジェクト（変更可能なオブジェクト）を許可するプログラミング言語では顕著です。実際、OOP言語の型チェッカーによって強制されるサブタイプ多態性は、すべてのコンテキストではないにしても、ほとんどのコンテキストにおいて動作サブタイプを保証することはできません。例えば、円と楕円の問題は、 OOPの継承の概念を使用して処理するのが非常に難しいことで知られています。動作サブタイプは一般に決定不可能であるため、コンパイラによって簡単に実装することはできません。そのため、プログラマーはプログラミング言語自体が検出できないミスを避けるために、クラス階層を慎重に設計する必要があります。

動的ディスパッチ

メソッドは、コンパイル時ではなく実行時に選択されるように、動的ディスパッチを介して呼び出される場合があります。メソッドの選択が複数のタイプのオブジェクト（パラメータとして渡される他のオブジェクトなど）に依存する場合、多重ディスパッチと呼ばれます。

動的ディスパッチは継承と連携して機能します。オブジェクトに要求されたメソッドがない場合、親クラス（委任）を参照し、チェーンを遡って一致するメソッドを見つけます

メッセージパッシング

メッセージパッシングとは、メソッド名とその入力がメッセージのようにオブジェクトに送信され、オブジェクトが処理することです。

ポリモーフィズム

ポリモーフィズムとは、サブタイピングまたはサブタイプポリモーフィズムを指します。これは、関数が特定のインターフェースと連携し、異なるクラスのエンティティを統一された方法で操作できることを意味します。[50]

たとえば、プログラムに円と四角形の2つの図形があるとします。どちらも「Shape」という共通クラスから来ています。それぞれの図形には独自の描画方法があります。サブタイプポリモーフィズムを使用すると、プログラムは各図形の型を知る必要がなく、各図形に対して「Draw」メソッドを呼び出すだけで済みます。プログラミング言語ランタイムは、各図形に対して正しいバージョンの「Draw」メソッドが実行されることを保証します。各図形の詳細は独自のクラス内で処理されるため、コードがよりシンプルで整理され、強力な関心の分離が可能になります。

オープン再帰

オブジェクトのメソッドは、オブジェクトのデータにアクセスできます。多くのプログラミング言語では、現在のオブジェクトを参照するために、 や のような特別な単語を使用します。オープン再帰をサポートする言語ではthis、オブジェクト内のメソッドは、この特別な単語を使用して、同じオブジェクト内の他のメソッド（自身を含む）を呼び出すことができます。これにより、あるクラスのメソッドは、サブクラスで後で定義された別のメソッドを呼び出すことができます。これは遅延バインディングと呼ばれる機能です。 self

デザインパターン

デザインパターンは、ソフトウェア設計における問題に対する一般的な解決策です。一部のデザインパターンはOOPに特に役立ち、通常はOOPのコンテキストで導入されます。

オブジェクトパターン

以下は、OOPオブジェクトの注目すべきソフトウェアデザインパターンです。[51]

一般的なアンチパターンは、 Godオブジェクトです。これは、あまりにも多くのことを知っている、または多くのことを行うオブジェクトです。

Gang of Fourのデザインパターン

『デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素』は、 1994年にErich Gamma、 Richard Helm、 Ralph Johnson、 John Vlissidesの4人の著者によって出版された有名な書籍です。彼らはしばしば「Gang of Four」と呼ばれます。この本は、OOPの長所と短所について述べ、プログラミングの問題を解決するための23の一般的な方法を説明しています。

これらのソリューションは「デザインパターン」と呼ばれ、3つのタイプに分類されます

オブジェクト指向とデータベース

OOPとリレーショナルデータベース管理システム（RDBMS）は、今日のソフトウェアで広く使用されています。しかし、リレーショナルデータベースはオブジェクトを直接保存しないため、両者を併用する際に課題が生じます。この問題は、オブジェクト・リレーショナル・インピーダンス・ミスマッチと呼ばれます。

この問題を解決するために、開発者はさまざまな方法を使用しますが、どれも完璧ではありません。[52]最も一般的な解決策の1つは、オブジェクト・リレーショナル・マッピング（ORM）です。これは、オブジェクト指向プログラムをリレーショナルデータベースに接続するのに役立ちます。ORMツールの例としては、Visual FoxPro、Java Data Objects、Ruby on Rails ActiveRecordなどがあります。

オブジェクトデータベースと呼ばれる一部のデータベースは、OOPで動作するように設計されています。しかし、リレーショナルデータベースほど普及しておらず、成功もしていません。

DateとDarwenは、RDBMSをサポートするための一種のカスタマイズ可能な型システムとしてOOPを使用する理論的基礎を提案しましたが、他のオブジェクトへのポインタを含むオブジェクトは禁止されています。[53]

責任駆動設計 vs. データ駆動設計

責任駆動設計では、クラスは契約の形で、実行する必要がある処理と共有する情報を中心に構築されます。これは、クラスが保存する必要があるデータに基づいて構築されるデータ駆動設計とは異なります。責任駆動設計の創始者であるWirfs-BrockとWilkersonによると、責任駆動設計の方が優れたアプローチです。[54]

SOLIDとGRASPのガイドライン

SOLIDは、Michael Feathersによって作成された、優れたソフトウェアを設計するための5つのルールのセットです。

  • 単一責任原則：クラスは変更する理由が1つだけである必要があります。
  • オープン/クローズ原則：ソフトウェアエンティティは拡張に対してオープンであるべきですが、変更に対してはクローズであるべきです。
  • リスコフ置換原則：基底クラスへのポインタまたは参照を使用する関数は、派生クラスのオブジェクトを知らないうちに使用できる必要があります。
  • インターフェース分離原則：クライアントは、使用しないインターフェースに依存することを強制されるべきではありません。
  • 依存性逆転原則：具象ではなく抽象に依存する

GRASP （一般責任割り当てソフトウェアパターン）は、クレイグ・ラーマンによって作成されたソフトウェア設計ルールのもう1つのセットで、開発者がプロ​​グラムのさまざまな部分に責任を割り当てるのに役立ちます。[55]

  • 作成者原則：クラスが密接に使用するオブジェクトを作成できるようにします。
  • 情報専門家原則：必要な情報を持つクラスにタスクを割り当てます
  • 低結合原則：クラスの依存関係を減らし、柔軟性と保守性を向上させます。
  • 高凝集原則：単一の集中した責任を持つクラスを設計します。
  • コントローラー原則：フローとインタラクションを管理する個別のクラスにシステム操作を割り当てます。
  • ポリモーフィズム：共通のインターフェースを介して異なるクラスを使用できるようにし、柔軟性と再利用性を促進します。
  • 純粋製造原則：ヘルパークラスを作成して、設計を改善し、凝集性を高め、結合性を低減します。

形式意味論

研究者たちはOOPのセマンティクスを正式に定義しようと試みてきました。継承は困難を伴い、特にオープン再帰とカプセル化された状態との相互作用において困難を伴います。研究者たちは再帰型と余代数的データ型を用いてOOPの本質的な機能を組み込んできました。[56] AbadiとCardelliは、可変オブジェクトを扱うSystem F <:のいくつかの拡張を定義し、サブタイプ多態性とパラメトリック多態性（ジェネリクス）の両方を可能にし、多くのOOPの概念と構成要素を正式にモデル化することができました。[57] Javaなどのオブジェクト指向プログラミング言語の静的解析は、決して簡単ではありませんが、成熟した分野であり、[58]いくつかの商用ツールがあります。[59]

批判

OOPはアルゴリズムやデータ構造よりもオブジェクトの使用に重点を置きすぎていると考える人もいます。[60] [61]例えば、プログラマーのRob Pikeは、OOPはプログラマーに型の構成よりも型の階層について考えさせる可能性があると指摘しました。[62]彼はOOPを「コンピューティングのローマ数字」と呼んでいます。[63] Clojureの作成者であるRich Hickeyは、特に時間の経過とともに変化する現実世界のものを表現する場合、OOPは過度に単純化されていると述べました。[61] Alexander Stepanovは、OOPはすべてを単一の型に当てはめようとするため、制限が生じる可能性があると述べました。彼は、ジェネリックプログラミングのように、複数の型にまたがるインターフェースのファミリーである、マルチソート代数が必要になる場合があると主張しました。Stepanovはまた、すべてを「オブジェクト」と呼んでも、理解があまり深まらないと述べました。[60]

OOPはコードの再利用と保守を容易にするために作成されました。[64]しかし、プログラムの命令の流れを明確に示すようには設計されていませんでした。それはコンパイラに委ねられていました。コンピュータが並列処理とマルチスレッドを使用するようになると、命令の流れを理解し制御することがより重要になりました。これはOOPでは困難です。[65] [66] [ 67] [68]

C++、Java、Pythonなど、多くの一般的なプログラミング言語はOOPを使用しています。かつてはOOPは広く受け入れられていましたが[69]、最近では一部のプログラマーがOOPを批判し、代わりに関数型プログラミングを好むようになっています。[70] Potokらによる研究では、OOPと他の手法の間に生産性に大きな違いは見られませんでした。[71]

著名なコンピュータ科学者であるポール・グレアムは、大企業がOOPを好むのは、平均的なプログラマーの大規模なチームの管理に役立つからだと考えています。彼は、OOPは構造を追加することで、一人のプログラマーが重大なミスを犯しにくくする一方で、優秀なプログラマーを抑制してしまうと主張しています。 [72] Unixプログラマーでありオープンソースソフトウェアの提唱者であるエリック・S・レイモンドは、OOPはプログラムを書くための最良の方法ではないと主張しています。[42]

リチャード・フェルドマンは、OOPの機能は一部の言語の体系性を維持するのに役立ったものの、その人気は他の理由から来ていると述べています。[73]ローレンス・クラブナーは、OOPは関数型プログラミングなどの他のスタイルと比較して特別な利点はなく、コーディングを複雑にする可能性があると主張しています。[74] ルカ・カルデッリは、OOPは手続き型プログラミングよりも遅く、コンパイルに時間がかかると述べています。[40]

参照

参考文献

  1. ^ abcd 「アラン・ケイ博士による「オブジェクト指向プログラミング」の意味について」2003年。2010年2月11日閲覧
  2. ^ Kindler, E.; Krivy, I. (2011). 「洗練された制御を備えたシステムのオブジェクト指向シミュレーション」. International Journal of General Systems . 40 (3): 313– 343. doi :10.1080/03081079.2010.539975.
  3. ^ Lewis, John; Loftus, William (2008). 「1.6: オブジェクト指向プログラミング」. Java Software Solutions . Foundations of Programming Design (6th ed.). Pearson Education Inc. ISBN 978-0-321-53205-3。
  4. ^ Booch, Grady (1986). Adaによるソフトウェアエンジニアリング. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8おそらく、オブジェクト指向開発アプローチの最大の強みは、現実世界のモデルを捉えるメカニズムを提供していることです。
  5. ^ Wirth, Niklaus (2006年1月23日). 「Good ideas, through the looking glass」(PDF) . IEEE Computer . Cover Feature. 39 (1): 28– 39. doi :10.1109/MC.2006.20. S2CID 6582369. 2016年10月12日時点の オリジナル(PDF)からのアーカイブ。
  6. ^ 「Uncle Bob SOLIDの原則」. YouTube . 2018年8月2日.
  7. ^ Meyer 1997, p. 230.
  8. ^ Yegge, Steve (2006年3月30日). 「Execution in the Kingdom of Nouns」. steve-yegge.blogspot.com . 2010年7月3日閲覧
  9. ^ Boronczyk, Timothy (2009年6月11日). 「OOPの何が問題なのか」zaemis.blogspot.com . 2010年7月3日閲覧.
  10. ^ Bloch 2018, pp. xi–xii, 序文
  11. ^ McCarthy, J. ; Brayton, R. ; Edwards, D. ; Fox, P. ; Hodes, L. ; Luckham, D. ; Maling, K. ; Park, D. ; Russell, S. (1969年3月). 「LISP I プログラマーズ・マニュアル」(PDF) .計算センター・電子工学研究所.マサチューセッツ州ボストン：人工知能グループ、MIT計算センター・電子工学研究所：88f. 2010年7月17日時点のオリジナル(PDF)からのアーカイブ。MITのローカルな方言では、[原子記号の]連想リストは「プロパティリスト」とも呼ばれ、原子記号は「オブジェクト」と呼ばれることもあります
  12. ^ マッカーシー、ジョン、アブラハムズ、ポール・W、エドワーズ、ダニエル・J、ハート、スワップニル・D、レビン、マイケル・I (1962). LISP 1.5 プログラマーズ・マニュアル. MIT Press . p. 105. ISBN 978-0-262-13011-0.オブジェクト – 原子記号の同義語 {{cite book}}: ISBN / Date incompatibility (help)
  13. ^ アイヴァン・E・サザーランド(1963年5月).スケッチパッド：マンマシン・グラフィカル・コミュニケーション・システム. AFIPS '63 (春): 1963年5月21～23日開催の春季合同コンピュータ会議議事録. AFIPSプレス.  329～ 346ページ. doi : 10.1145/1461551.1461591
  14. ^ ab Nygaard, Kristen ; Dahl, Ole-Johan (1978年8月1日). "The development of the SIMULA languages". ACM SIGPLAN Notices . 13 (8): 245– 272. doi : 10.1145/ 960118.808391
  15. ^ ロス、ダグ。「最初のソフトウェア工学言語」。LCS /AIラボタイムライン。MITコンピュータ科学・人工知能研究所。 2010年5月13日閲覧。
  16. ^ ホルメヴィク、ヤン・ルネ（1994年冬）。「Simulaのコンパイル：技術的起源の歴史的研究」（PDF）。IEEE Annals of the History of Computing。16（4）：25–37。doi：10.1109/85.329756。S2CID 18148999。 2017年8月30日時点 のオリジナル（PDF）からアーカイブ。 2018年3月3日閲覧。
  17. ^マドセン、 レーマン。「クリステン・ナイガード」。AMチューリング賞受賞者。2025年2月4日閲覧
  18. ^ ブッチャー、ポール（2014年6月30日）. 7週間で学ぶ7つの並行性モデル：スレッドが解きほぐれるとき. Pragmatic Bookshelf. p. 204. ISBN 978-1-68050-466-8。
  19. ^ ジョーンズ、アニタ・K.、リスコフ、バーバラ・H.（1976年4月）. プログラミング言語のためのアクセス制御機能（PDF）（技術レポート）. MIT. CSGメモ137.
  20. ^ バート ランド・マイヤー（2009年）.タッチ・オブ・クラス：オブジェクトとコントラクトを使ったプログラミングの習得. Springer Science & Business Media. p. 329.書誌コード：2009tclp.book.....M. ISBN 978-3-540-92144-8。
  21. ^ アラン・C・ケイ（1993年3月）「Smalltalkの初期の歴史」ACM SIGPLAN Notices . 28 (3): 69–95 . doi : 10.1145/15536​​0.15536 ​​4.
  22. ^ アラン・ハミルトン・ボーニング（1979年）Thinglab：制約指向シミュレーション実験室（PDF）（レポート）スタンフォード大学
  23. ^ Moon, David A. (1986年6月). 「オブジェクト指向プログラミングとフレーバー」(PDF) .オブジェクト指向プログラミングシステム言語とアプリケーションに関する会議議事録. OOPSLA '86. pp.  1– 8. doi :10.1145/28697.28698. ISBN 978-0-89791-204-4. S2CID  17150741. 2022年3月17日閲覧.
  24. ^ 「Smalltalk Zooの紹介」. CHM . 2020年12月17日.
  25. ^ Bobrow, DG; Stefik, M. J (1982). LOOPS: Interlispのためのデータとオブジェクト指向プログラミング(PDF) . ヨーロッパAI会議.
  26. ^ Meyer 1997
  27. ^ 1995年（6月）Visual FoxPro 3.0。FoxProは手続き型言語からオブジェクト指向言語へと進化しました。Visual FoxPro 3.0では、データベースコンテナ、シームレスなクライアント/サーバー機能、ActiveXテクノロジのサポート、OLEオートメーションとnullサポートが導入されました。Foxリリースの概要
  28. ^ 1995年 Visual FoxPro 3.0 レビューアーズガイド：DFpug.de
  29. ^ Khurana, Rohit（2009年11月1日）。『C++によるオブジェクト指向プログラミング』第1版。Vikas Publishing House Pvt Limited。ISBN  978-81-259-2532-3。
  30. ^ Deborah J. Armstrong. The Quarks of Object-Oriented Development . 約40年にわたるコンピューティング文献の調査により、OOPの定義の大部分に見られるいくつかの基本概念が特定されました。人気の高い順に、継承、オブジェクト、クラス、カプセル化、メソッド、メッセージパッシング、ポリモーフィズム、抽象化です。
  31. ^ John C. Mitchell , Concepts in programming languages , Cambridge University Press, 2003, ISBN 0-521-78098-5、278ページ。リスト：動的ディスパッチ、抽象化、サブタイプポリモーフィズム、継承
  32. ^ マイケル・リー・スコット著『プログラミング言語語用論』第2版、モーガン・カウフマン、2006年、 ISBN 0-12-633951-1470ページ。カプセル化、継承、動的ディスパッチについて列挙している。
  33. ^ ピアス、ベンジャミン (2002) 『型とプログラミング言語』MIT出版、ISBN 978-0-262-16209-8。セクション18.1「オブジェクト指向プログラミングとは何か？」では、動的ディスパッチ、カプセル化またはマルチメソッド（多重ディスパッチ）、サブタイプの多態性、継承または委譲、オープン再帰（「this」/「self」）について説明しています。
  34. ^ CJ Date著、『データベースシステム入門』第6版、650ページ
  35. ^ McDonough, James E. (2017). 「カプセル化」. ABAPによるオブジェクト指向設計：実践的アプローチ. Apress . doi :10.1007/978-1-4842-2838-8. ISBN 978-1-4842-2837-1– O'Reilly経由
  36. ^ Bloch 2018, pp. 73–77, Chapter §4 項目15 クラスとメンバーのアクセシビリティを最小限に抑える.
  37. ^ 「オブジェクト指向プログラミング（OOP）とは？簡単な言葉で言うと？ – Software Geek Bytes」. 2023年1月5日. 2023年1月17日時点のオリジナルよりアーカイブ。2023年1月17日閲覧
  38. ^ ルカ・カルデッリ、ピーター・ウェグナー（1985年12月10日）「型、データ抽象化、ポリモーフィズムの理解について」ACMコンピューティングサーベイ、17（4）、471～ 523 、 doi：10.1145/6041.6042、ISSN  0360-0300
  39. ^ アイヴァー・ヤコブセン、マグナス・クリスターソン、パトリック・ジョンソン、グンナー・オーバーガード（1992年）。オブジェクト指向ソフトウェア工学。Addison-Wesley ACM Press、pp. 43～69。ISBN  978-0-201-54435-0。
  40. ^ abc Cardelli, Luca (1996). 「オブジェクト指向言語の悪いエンジニアリング特性」 . ACM Comput. Surv . 28 (4es): 150–es. doi :10.1145/242224.242415. ISSN  0360-0300. S2CID  12105785. 2010年4月21日閲覧。
  41. ^ ab Armstrong, Joe . Seibel, Peter (ed.). Coders at Work: Reflections on the Craft of Programming. Codersatwork.com. 2010年3月5日時点のオリジナルからのアーカイブ。 2009年11月13日閲覧。
  42. ^ abc Raymond, Eric S. (2003). 「Unixプログラミングの芸術：Unixとオブジェクト指向言語」. 2014年8月6日閲覧
  43. ^ Brodie, Leo (1984). Thinking Forth (PDF) . pp.  92– 93. 2018年5月4日閲覧.
  44. ^ Hunt, Andrew. "Don't Repeat Yourself".カテゴリ：エクストリームプログラミング. 2018年5月4日閲覧
  45. ^ Bloch 2018, p. 19, Chapter §2 項目4 プライベートコンストラクタを使用してインスタンス化不可能性を強制する
  46. ^ Dony, C; Malenfant, J; Bardon, D (1999). 「プロトタイプベースプログラミング言語の分類」(PDF) .プロトタイプベースプログラミング：概念、言語、アプリケーション. シンガポール・ベルリン・ハイデルベルク: Springer. ISBN 9789814021258。
  47. ^ 「Goはオブジェクト指向言語か？」 。 2019年4月13日閲覧。Goには型とメソッドがあり、オブジェクト指向スタイルのプログラミングが可能ですが、型階層はありません。
  48. ^ Stroustrup, Bjarne (2015). 継承のないオブジェクト指向プログラミング（招待講演）. 第29回ヨーロッパオブジェクト指向プログラミング会議 (ECOOP 2015). 1:34. doi : 10.4230/LIPIcs.ECOOP.2015.1 .
  49. ^ Pike, Rob (2012年11月14日). 「数年前、私はこのページを見ました。」。2018年8月14日時点のオリジナルからのアーカイブ。2016年10月1日閲覧
  50. ^ Stroustrup, Bjarne (2007年2月19日). 「Bjarne StroustrupのC++用語集」.ポリモーフィズム – 異なる型のエンティティに単一のインターフェースを提供すること。
  51. ^ Martin, Robert C.「設計原則とデザインパターン」(PDF) . 2015年9月6日時点のオリジナル(PDF)からのアーカイブ。 2017年4月28日閲覧。
  52. ^ Neward, Ted (2006年6月26日). 「コンピュータサイエンスのベトナム」. 相互運用性は起こる。2006年7月4日時点のオリジナルからのアーカイブ。 2010年6月2日閲覧。
  53. ^ CJ Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (第2版)
  54. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). 「オブジェクト指向設計：責任駆動型アプローチ」. ACM SIGPLAN Notices . 24 (10): 74. doi : 10.1145/74878.74885 .
  55. ^ Karsh, Patrick (2023年7月19日). 「GRASP原則：オブジェクト指向設計パターン」. Medium . 2025年3月30日閲覧.
  56. ^ Poll, Erik. 「カテゴリカルデータ型のサブタイピングと継承」(PDF) . 2011年6月5日閲覧.
  57. ^ Abadi, Martin ; Cardelli, Luca (1996). 「オブジェクトの理論」. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-42010年4月21日閲覧
  58. ^ Tan, Tian; Li, Yue (2023年7月12日). Tai-e: 古典の優れた設計を活用した開発者フレンドリーなJava向け静的解析フレームワーク. ISSTA 2023. pp.  1093– 1105. doi :10.1145/3597926.3598120.
  59. ^ Bhutani, Vikram; Toosi, Farshad Ghassemi; Buckley, Jim (2024年6月1日). 「アナライザーの分析：ソースコード分析ツールの調査」. Applied Computer Systems . 29 (1): 98–111 . doi :10.2478/acss-2024-0013.
  60. ^ ab Stepanov, Alexander (2001–2008). 「STLport：A. Stepanovへのインタビュー」. 2010年4月21日閲覧.
  61. ^ ab Hickey, Rich (2009年11月). 「Are We There Yet? (基調講演). JVM Languages Summit.
  62. ^ Pike, Rob (2012年6月25日). 「Less is exponentially more」 . 2016年10月1日閲覧
  63. ^ Pike, Rob (2004年3月2日). 「[9fans] Re: Threads: Sewing badges of honor onto a Kernel」. comp.os.plan9 (メーリングリスト) . 2016年11月17日閲覧.
  64. ^ Ambler, Scott (1998年1月1日). 「A Realistic Look at Object-Oriented Reuse」. drdobbs.com . 2025年8月5日閲覧.
  65. ^ Shelly, Asaf (2008年8月22日). 「Flaws of Object Oriented Modeling」. Intel Software Network . 2010年7月4日閲覧.
  66. ^ James, Justin (2007年10月1日). 「Multithreading is a verb not a noun」. techrepublic.com. 2007年10月10日時点のオリジナルよりアーカイブ. 2010年7月4日閲覧
  67. ^ Shelly, Asaf (2008年8月22日). 「HOW TO: マルチコアプログラミング（マルチプロセス）Visual C++ クラス設計ガイドライン、メンバー関数」. support.microsoft.com . 2010年7月4日閲覧.
  68. ^ Robert Harper (2011年4月17日). 「FPの教え方に関する考察」. Existential Type Blog . 2011年12月5日閲覧.
  69. ^ Brucker, Achim D.; Wolff, Burkhart (2008). 「オブジェクト指向データモデルのための拡張可能なユニバース」. ECOOP 2008 – オブジェクト指向プログラミング. コンピュータサイエンス講義ノート. 第5142巻. pp.  438– 462. doi :10.1007/978-3-540-70592-5_19. ISBN 978-3-540-70591-8 オブジェクト指向プログラミングは広く受け入れられているプログラミングパラダイムです
  70. ^ Cassel, David (2019年8月21日). 「なぜ多くの開発者がオブジェクト指向プログラミングを嫌うのか？」The New Stack .
  71. ^ Potok, Thomas; Vouk, Mladen; Rindos, Andy (1999). 「商用環境で開発されたオブジェクト指向ソフトウェアの生産性分析」(PDF) . Software: Practice and Experience . 29 (10): 833– 847. doi :10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. S2CID  57865731. 2010年4月21日閲覧.
  72. ^ Graham, Paul . 「なぜARCは特にオブジェクト指向ではないのか」. PaulGraham.com . 2009年11月13日閲覧
  73. ^ フェルドマン、リチャード（2019年9月30日）「なぜ関数型プログラミングは標準ではないのか？」YouTube
  74. ^ クルブナー、ローレンス「オブジェクト指向プログラミングは、終わらせなければならない高価な災害である」smashcompany.com。2014年10月14日時点のオリジナルからのアーカイブ。 2014年10月14日閲覧。

参考文献

Wikiquoteには、オブジェクト指向に関する引用があります。
Wikiversityには、オブジェクト指向プログラミングに関する学習リソースがあります。
トピック：オブジェクト
Wikibooksには、オブジェクト指向プログラミングに関する書籍があります。
  • LWC Nirosh著『オブジェクト指向プログラミングの概念（OOP）入門』
  • OOPの欠点に関する議論
  • OOPの概念（Javaチュートリアル）