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

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

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

OOPをサポートする著名な言語としては、Ada、ActionScript、C++、Common Lisp、C#、Dart、Eiffel、Fortran 2003、Haxe、Java、[ 4 ] 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のアトムを指していました。 [ 5 ] [ 6 ] もう一つの初期の例として、 1960年から1961年にかけてMITでアイヴァン・サザーランドが作成したスケッチパッドが挙げられます。サザーランドは技術報告書の用語集で、「オブジェクト」や「インスタンス」（クラス概念は「マスター」または「定義」でカバー）といった用語を定義しましたが、これらはグラフィカルなインタラクションに特化されていました。[ 7 ]その後、1968年にMIT版ALGOLプログラミング言語であるAED-0がデータ構造（「プレックス」）とプロシージャを結び付け、後に「メッセージ」、「メソッド」、「メンバー関数」と呼ばれるようになるものの先駆けとなりました。[ 8 ] [ 9 ]データ抽象化やモジュールプログラミング などのトピックは、当時の一般的な議論の焦点でした。

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

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

アラン・ケイ[ 1 ]

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

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

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

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

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

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

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

特徴

OOPの機能は言語によって様々です。以下はOOP言語に共通する機能です。[ 24 ] [ 25 ] [ 26 ] [ 27 ] OOPをリレーショナルプログラミングなどの他のスタイルと比較するのは困難です。なぜなら、OOPには明確で合意された定義がないからです。[ 28 ]

カプセル化と情報の隠蔽

情報の隠蔽とカプセル化は、いくつかの関連する概念を指す場合があります。

  • 凝集性：関連するフィールドとメソッドをまとめる。フィールド（属性またはプロパティとも呼ばれる）は、情報（状態とも呼ばれる）を変数として保持する。メソッド（関数またはアクションとも呼ばれる）は、ロジックコードを介して動作を定義する。
  • 分離とは、コードの特定の部分のみが関連する関数によって使用されるようにコードを整理することです。分離により、コードリファクタリングなどにおいて、コードベースの他の部分に影響を与えることなく、オブジェクトの内部動作を変更することが容易になります。[ 29 ]オブジェクトは、内部動作と外部の消費コードとの間の境界として機能します。
  • データ隠蔽とは、オブジェクトの内部情報を外部コードから隠蔽することです。言語が可視性を制御するアクセス修飾子を提供しているため、オブジェクトを利用するコードは、オブジェクトのパブリックメンバーを介してのみ操作できます。

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

情報隠蔽とデータ抽象化の支持者は、それによってコードの再利用が容易になり、現実世界の状況を直感的に表現できるようになると主張している。[ 32 ] [ 33 ]しかし、OOPは可読性やモジュール性を向上させないと主張する者もいる。[ 34 ] [ 35 ]エリック・S・レイモンドは、OOP言語は透明性を損なう厚い階層のプログラムを促進する傾向があると書いている。[ 36 ]レイモンドはこれをUnixやC言語で取られたアプローチと比較して不利である。[ 36 ]

SOLIDにはオープン/クローズ原則が含まれており、クラスと関数は「拡張に対してはオープンであるべきであるが、変更に対してはクローズであるべき」とされています。Luca Cardelliは、OOP言語は「クラスの拡張と変更に関してモジュール性が非常に低い」ため、非常に複雑になりがちであると述べています。[ 34 ]後者の点は、 Erlangの主要な発明者であるJoe Armstrongによって繰り返されており、彼は次のように述べています。[ 35 ]

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

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

継承

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

階級に基づく

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

  • クラス変数– クラス自体に属し、クラスのすべてのオブジェクトが1つのコピーを共有する
  • インスタンス変数– オブジェクトに属します。すべてのオブジェクトは独自のインスタンス変数を持っています。
  • メンバー変数– クラスのクラス変数とインスタンス変数の両方を指します
  • クラスメソッド – クラス変数のみ使用可能
  • インスタンスメソッド - オブジェクトに属し、インスタンス変数とクラス変数の両方を使用できる

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

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

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

プロトタイプベース

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

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

継承なし

すべての OOP 言語では、オブジェクトの合成によって、オブジェクトは他のオブジェクトを含むことができます。たとえば、オブジェクトはオブジェクト と、その他の情報や などをEmployee含むことができます。合成は、「従業員は住所を持っている」のような「has-a」関係です。Go などの一部の言語は継承をサポートしていません。[ 41 ]代わりに、親子関係ではなく小さな部分を使用してオブジェクトが構築される「継承よりも合成」が推奨されます。たとえば、Employee クラスは、Person クラスから継承する代わりに、単に Person オブジェクトを含むことができます。これにより、Employee クラスは、Person のどの程度をプログラムの他の部分に公開するかを制御できます。委任は、継承の代替として使用できるもう 1 つの言語機能です。 Addressnameposition

プログラマーの間では継承について様々な意見があります。C++の作者であるBjarne Stroustrupは、継承なしでもOOPは可能だと述べています。[ 42 ] Rob Pikeは、継承はより単純な解決策ではなく複雑な階層構造を生み出すと批判しています。[ 43 ]

継承と動作のサブタイプ化

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

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

動的ディスパッチ

メソッドは動的ディスパッチによって呼び出される場合があります。この場合、メソッドはコンパイル時ではなく実行時に選択されます。メソッドの選択が複数の種類のオブジェクト（例えば、パラメータとして渡される他のオブジェクト）に依存する場合、これは多重ディスパッチと呼ばれます。この文脈では、メソッド呼び出しはメッセージパッシングとも呼ばれ、メソッド名とその入力は、オブジェクトに送信されるメッセージのようなもので、オブジェクトはそれに基づいて動作します。[ 44 ]

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

多態性

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

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

オープン再帰

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

デザインパターン

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

現実世界のモデリングと関係

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

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

オブジェクトパターン

以下はOOPオブジェクトの注目すべきソフトウェア設計パターンです。 [ 52 ]

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

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

『デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素』は、1994年にエリック・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシデスの4人の著者によって出版された有名な書籍です。彼らはしばしば「4人組」と呼ばれています。本書では、オブジェクト指向プログラミング（OOP）の長所と短所について論じ、プログラミング上の問題を解決するための23の一般的な方法を解説しています。

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

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

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

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

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

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

責任重視設計 vs. データ重視設計

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

SOLIDとGRASPガイドライン

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

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

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

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

形式意味論

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

人気と受容

2002年から2023年までのTIOBEプログラミング言語人気指数グラフ。2000年代には、オブジェクト指向のJava（オレンジ）と手続き型のC （濃い青）がトップの座を競い合っていました。

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

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

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

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

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

参照

参考文献

  1. ^ a b c dケイ、アラン博士（2003年7月23日）。「アラン・ケイ博士による「オブジェクト指向プログラミング」の意味について」. 2025年3月4日時点のオリジナルよりアーカイブ。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ソフトウェアソリューション. プログラミング設計の基礎（第6版）. Pearson Education Inc. ISBN 978-0-321-53205-3。
  4. ^ Bloch 2018、pp. xi–xii、序文。
  5. ^ McCarthy, J. ; Brayton, R. ; Edwards, D. ; Fox, P. ; Hodes, L. ; Luckham, D. ; Maling, K. ; Park, D. ; Russell, S. (1969年3月). "LISP I Programmers Manual" (PDF) . Computation Center and Research Laboratory of Electronics . Boston , Massachusetts : Artificial Intelligence Group, MIT Computation Center and Research Laboratory: 88f. 2010年7月17日時点のオリジナル(PDF)からのアーカイブ。MITのローカルな方言では、連想リスト（原子記号）は「プロパティリスト」とも呼ばれ、原子記号は「オブジェクト」と呼ばれることもあります。
  6. ^マッカーシー, ジョン; エイブラハムズ, ポール W.; エドワーズ, ダニエル J.; ハート, スワップニル D.; レビン, マイケル I. (1962). LISP 1.5 プログラマーズ・マニュアル. MIT プレス. p.  105. ISBN 978-0-262-13011-0.オブジェクト – 原子記号の同義語{{cite book}}:ISBN / 日付の非互換性（ヘルプ）
  7. ^ Ivan E. Sutherland (1963年5月). Sketchpad: a man-machine graphical communication system . AFIPS '63 (Spring): Proceedings of the May 21–23, 1963 Spring Joint Computer Conference. AFIPS Press. pp.  329– 346. doi : 10.1145/1461551.1461591 .
  8. ^ a b Nygaard, Kristen ; Dahl, Ole-Johan (1978年8月1日). 「SIMULA言語の開発」 . ACM SIGPLAN Notices . 13 (8): 245– 272. doi : 10.1145/960118.808391 .
  9. ^ロス、ダグ. 「最初のソフトウェアエンジニアリング言語」 . LCS/AIラボタイムライン. MITコンピュータサイエンスおよび人工知能研究所. 2010年5月13日閲覧。{{cite web}}: CS1 maint: url-status (リンク)
  10. ^ a b Holmevik, Jan Rune (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日閲覧。 
  11. ^マドセン、オーレ・レーマン。「クリステン・ナイガード」。AM チューリング賞受賞者。2025 年2 月 4 日に取得。
  12. ^ブッチャー、ポール（2014年6月30日）『7週間で学ぶ7つの並行性モデル：スレッドが解けるとき』プラグマティック・ブックシェルフ、204ページ。ISBN 978-1-68050-466-8。
  13. ^ Jones, Anita K.; Liskov, Barbara H. (1976年4月).プログラミング言語のためのアクセス制御機能(PDF) (技術レポート). MIT. CSG Memo 137.
  14. ^ a b Bertrand Meyer (2009). 『Touch of Class: Learning to Program Well with Objects and Contracts』 Springer Science & Business Media. p. 329. Bibcode : 2009tclp.book.....M . ISBN 978-3-540-92144-8。
  15. ^ Alan C. Kay (1993年3月). 「Smalltalkの初期の歴史」 . ACM SIGPLAN Notices . 28 (3): 69– 95. doi : 10.1145/15536​​0.15536 ​​4.
  16. ^ Borning, Alan Hamilton (1979). Thinglab: 制約指向シミュレーション実験室(PDF) (レポート). スタンフォード大学.
  17. ^ムーン、デイビッド・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日閲覧。
  18. ^ Hsu, Hansen (2020年12月17日). 「Introducing the Smalltalk Zoo」 . CHM . 2021年5月27日閲覧。{{cite news}}: CS1 maint: url-status (リンク)
  19. ^ Bobrow, DG; Stefik, M. J (1982). LOOPS: Interlisp のためのデータおよびオブジェクト指向プログラミング(PDF) . ヨーロッパAI会議.
  20. ^マイヤー 1997 .
  21. ^ 1995年（6月） Visual FoxPro 3.0。FoxProは手続き型言語からオブジェクト指向言語へと進化しました。Visual FoxPro 3.0では、データベースコンテナ、シームレスなクライアント/サーバー機能、ActiveXテクノロジのサポート、OLEオートメーションとNULLサポートが導入されました。Foxリリースの概要
  22. ^ 1995 Visual FoxPro 3.0 レビューガイド: DFpug.de
  23. ^ Khurana, Rohit (2009年11月1日). Object Oriented Programming with C++, 1E . Vikas Publishing House Pvt Limited. ISBN 978-81-259-2532-3。
  24. ^ Deborah J. Armstrong.オブジェクト指向開発のクォーク。約40年にわたるコンピューティング文献の調査により、OOPの定義の大部分に見られるいくつかの基本概念が特定されました。人気の高い順に、継承、オブジェクト、クラス、カプセル化、メソッド、メッセージパッシング、ポリモーフィズム、抽象化です。
  25. ^ジョン・C・ミッチェル著『プログラミング言語の概念』ケンブリッジ大学出版局、2003年、 ISBN 0-521-78098-5、p.278。リスト：動的ディスパッチ、抽象化、サブタイプ多態性、継承。
  26. ^マイケル・リー・スコット著『プログラミング言語語用論』第2版、モーガン・カウフマン、2006年、 ISBN 0-12-633951-1、p. 470。カプセル化、継承、動的ディスパッチをリストします。
  27. ^ピアス、ベンジャミン (2002).型とプログラミング言語. MIT 出版. ISBN 978-0-262-16209-8。セクション18.1「オブジェクト指向プログラミングとは何か？」では、動的ディスパッチ、カプセル化またはマルチメソッド（多重ディスパッチ）、サブタイプの多態性、継承または委譲、オープン再帰（「this」/「self」）について説明しています。
  28. ^ CJ Date, データベースシステム入門, 第6版, 650ページ
  29. ^ McDonough, James E. (2017). 「カプセル化」. ABAPによるオブジェクト指向設計：実践的アプローチ. Apress . doi : 10.1007/978-1-4842-2838-8 . ISBN 978-1-4842-2837-1– O'Reilly経由。
  30. ^ Bloch 2018、pp. 73–77、第4章 §15 項目 クラスとメンバーのアクセシビリティを最小限に抑えます。
  31. ^ “What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes” . 2023年1月5日. 2023年1月17日時点のオリジナルよりアーカイブ。 2023年1月17日閲覧。
  32. ^ Cardelli, Luca; Wegner, Peter (1985年12月10日). 「型、データ抽象化、そして多態性の理解について」 . ACM Computing Surveys . 17 (4): 471– 523. doi : 10.1145/6041.6042 . ISSN 0360-0300 . 
  33. ^イーヴァル、ヤコブセン;マグナス・クリスターソン。パトリック・ヨンソン。グンナー・オーバーガード (1992)。オブジェクト指向ソフトウェアエンジニアリング。アディソン・ウェスリー ACM プレス。43–69ページ 。ISBN 978-0-201-54435-0。
  34. ^ a b c Cardelli, Luca (1996). 「オブジェクト指向言語の不適切なエンジニアリング特性」 . ACM Comput. Surv . 28 (4es): 150–es. doi : 10.1145/242224.242415 . ISSN 0360-0300 . S2CID 12105785. 2010年4月21日閲覧。  
  35. ^ a bジョー・アームストロング著、ピーター・セイベル編著『Coders at Work: Reflections on the Craft of Programming』、Codersatwork.com。2010年3月5日時点のオリジナルよりアーカイブ。 2009年11月13日閲覧。
  36. ^ a b c Raymond, Eric S. (2003). 「Unixプログラミングの技法：Unixとオブジェクト指向言語」 . 2014年8月6日閲覧。
  37. ^ Brodie, Leo (1984). Thinking Forth (PDF) . pp.  92– 93. 2018年5月4日閲覧。
  38. ^ Hunt, Andrew. 「Don't Repeat Yourself」カテゴリー：エクストリームプログラミング2018年5月4日閲覧。
  39. ^ Bloch 2018、p. 19、第2章項目4プライベートコンストラクターでインスタンス化不可能性を強制します。
  40. ^ Dony, C; Malenfant, J; Bardon, D (1999). 「プロトタイプベースプログラミング言語の分類」(PDF) .プロトタイプベースプログラミング：概念、言語、応用. シンガポール・ベルリン・ハイデルベルク: Springer. ISBN 9789814021258。
  41. ^ 「Goはオブジェクト指向言語か？」2019年4月13日閲覧。Goには型とメソッドがあり、オブジェクト指向のプログラミングスタイルが可能ですが、型階層はありません。{{cite web}}: CS1 maint: url-status (リンク)
  42. ^ Stroustrup, Bjarne (2015).継承を使用しないオブジェクト指向プログラミング（招待講演） . 第29回ヨーロッパオブジェクト指向プログラミング会議 (ECOOP 2015). 1:34. doi : 10.4230/LIPIcs.ECOOP.2015.1 .
  43. ^ Pike, Rob (2012年11月14日). 「数年前、私はこのページを見た」 。 2018年8月14日時点のオリジナルよりアーカイブ。2016年10月1日閲覧。
  44. ^ Naik, Mayur; Kumar, Rajeev (2000年3月). 「オブジェクト指向システムにおける効率的なメッセージディスパッチ」. ACM SIGPLAN Notices . 35 (3): 49– 58. doi : 10.1145/351159.351174 .
  45. ^ Stroustrup, Bjarne (2007年2月19日). 「Bjarne StroustrupのC++用語集」 . 2011年6月9日閲覧。ポリモーフィズム – 異なる型のエンティティに対して単一のインターフェースを提供すること。{{cite web}}: CS1 maint: url-status (リンク)
  46. ^ Booch, Grady (1986). Adaによるソフトウェアエンジニアリング. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8おそらく、オブジェクト指向開発アプローチの最大の強みは、現実世界のモデルを捉えるメカニズムを提供していることです。
  47. ^ Wirth, Niklaus (2006年1月23日). 「Good ideas, through the looking glass」(PDF) . IEEE Computer . Cover Feature. 39 (1): 28– 39. Bibcode : 2006Compr..39a..28W . doi : 10.1109/MC.2006.20 . S2CID 6582369. 2016年10月12日時点のオリジナル(PDF)からのアーカイブ。 
  48. ^ 「アンクルボブのSOLID原則」YouTube。2018年8月2日。
  49. ^マイヤー 1997、230ページ。
  50. ^ Yegge, Steve (2006年3月30日). 「名詞の王国における処刑」 . steve-yegge.blogspot.com . 2010年7月3日閲覧。
  51. ^ Boronczyk, Timothy (2009年6月11日). 「OOPの何が問題なのか」 zaemis.blogspot.com . 2010年7月3日閲覧。
  52. ^ Martin, Robert C. 「デザイン原則とデザインパターン」(PDF) 。 2015年9月6日時点のオリジナル(PDF)からアーカイブ。 2017年4月28日閲覧。
  53. ^ Neward, Ted (2006年6月26日). 「コンピュータサイエンスのベトナム」 . 相互運用性は起こる. 2006年7月4日時点のオリジナルよりアーカイブ。2010年6月2日閲覧。
  54. ^ CJ Date、Hugh Darwen著『未来のデータベースシステムのための財団：第三の宣言（第2版）』
  55. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). 「オブジェクト指向設計：責任駆動型アプローチ」 . ACM SIGPLAN Notices . 24 (10): 74. doi : 10.1145/74878.74885 .
  56. ^ Karsh, Patrick (2023年7月19日). 「GRASPの原則：オブジェクト指向設計パターン」 . Medium . 2025年3月30日閲覧。
  57. ^ Poll, Erik. 「カテゴリカルデータ型のサブタイプと継承」(PDF) . 2011年6月5日閲覧。
  58. ^マーティン・アバディ;ルカ・カーデリ（1996）。オブジェクトの理論。 Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. 2010年4月21日閲覧。
  59. ^ Tan, Tian; Li, Yue (2023年7月12日). Tai-e: 古典の優れた設計を活用した開発者フレンドリーなJava向け静的解析フレームワーク. ISSTA 2023. pp.  1093– 1105. doi : 10.1145/3597926.3598120 .
  60. ^ Bhutani, Vikram; Toosi, Farshad Ghassemi; Buckley, Jim (2024年6月1日). 「アナライザーの分析：ソースコード解析ツールの調査」. Applied Computer Systems . 29 (1): 98–111 . doi : 10.2478/acss-2024-0013 .
  61. ^ 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オブジェクト指向プログラミングは広く受け入れられているプログラミングパラダイムである
  62. ^ Cassel, David (2019年8月21日). 「なぜ多くの開発者がオブジェクト指向プログラミングを嫌うのか？」 The New Stack .
  63. ^ Potok, Thomas; Vouk, Mladen; Rindos, Andy (1999). 「商用環境で開発されたオブジェクト指向ソフトウェアの生産性分析」(PDF) .ソフトウェア：実践と経験. 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日閲覧. 
  64. ^ a b Stepanov, Alexander (2001–2008). 「STLport: A. Stepanovへのインタビュー」 . 2010年4月21日閲覧。
  65. ^ a b Hickey, Rich (2009年11月). Are We There Yet? (基調講演) . JVM Languages Summit.
  66. ^ Pike, Rob (2012年6月25日). 「Less is exponentially more」 . 2016年10月1日閲覧。
  67. ^ Pike, Rob (2004年3月2日). 「[9fans] Re: Threads: Sewing badges of honor onto a Kernel」 . comp.os.plan9 (メーリングリスト) . 2016年11月17日閲覧。
  68. ^ Ambler, Scott (1998年1月1日). 「オブジェクト指向による再利用の現実的な考察」 . drdobbs.com . 2025年8月5日閲覧。
  69. ^ Shelly, Asaf (2008年8月22日). 「オブジェクト指向モデリングの欠陥」 . Intel Software Network . 2010年7月4日閲覧。
  70. ^ James, Justin (2007年10月1日). 「マルチスレッドは名詞ではなく動詞である」 . techrepublic.com. 2007年10月10日時点のオリジナルよりアーカイブ。2010年7月4日閲覧。
  71. ^ Shelly, Asaf (2008年8月22日). 「HOW TO: マルチコアプログラミング（マルチプロセッシング）Visual C++ クラス設計ガイドライン、メンバー関数」 . support.microsoft.com . 2010年7月4日閲覧。
  72. ^ Robert Harper (2011年4月17日). 「FPの指導に関する考察」 Existential Type Blog . 2011年12月5日閲覧。
  73. ^グレアム、ポール. 「なぜARCは特にオブジェクト指向ではないのか」 . PaulGraham.com . 2009年11月13日閲覧。
  74. ^フェルドマン、リチャード（2019年9月30日）「なぜ関数型プログラミングは標準ではないのか？」YouTube
  75. ^ Krubner, Lawrence. 「オブジェクト指向プログラミングは、終わらせなければならない高価な災害である」 . smashcompany.com. 2014年10月14日時点のオリジナルよりアーカイブ。 2014年10月14日閲覧。

さらに読む

Wikiquote にはオブジェクト指向に関連する引用があります。
Wikiversityにはオブジェクト指向プログラミングに関する学習リソースがあります。
Wikibooksにはオブジェクト指向プログラミングに関する本があります。
「 https://en.wikipedia.org/w/index.php?title=オブジェクト指向プログラミング&oldid =1331466434」より取得