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

オブジェクト指向プログラミング（OOP）は、オブジェクトの概念に基づくプログラミングパラダイムです。 ^[1]オブジェクトには、フィールド（属性またはプロパティと呼ばれることが多い）の形式のデータと、プロシージャ（メソッドと呼ばれることが多い）の形式のコードという、データとコードを含めることができます。OOPでは、コンピュータプログラムは、互いに相互作用するオブジェクトから作成して設計されます。^{[2] [3]}

最も広く使用されているプログラミング言語の多く（C++、Java、^[4]、Pythonなど）はマルチパラダイムであり、通常は命令型プログラミング、手続き型プログラミング、関数型プログラミングと組み合わせて、多かれ少なかれオブジェクト指向プログラミングをサポートしています。

重要なオブジェクト指向言語としては、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]} MITの初期の例としては、1960年から1961年にかけてIvan Sutherlandが作成したSketchpadがあります。Sketchpadに関する博士論文に基づく1963年の技術レポートの用語集で、Sutherlandは「オブジェクト」と「インスタンス」（クラスの概念は「マスター」または「定義」でカバー）という概念を定義しましたが、これはグラフィカルなインタラクションに特化していました。^[7] また、1968年には、MIT ALGOLバージョンであるAED-0が、データ構造（当時の方言では「プレックス」）とプロシージャを直接リンクさせ、後に「メッセージ」、「メソッド」、「メンバー関数」と呼ばれるようになったものの先駆けとなりました。^{[8] [9]}データ抽象化やモジュールプログラミング などのトピックは、当時の一般的な議論の焦点でした。

Simulaは、AEDなどの後のMITの研究とは独立して、1961年から1967年にかけて開発されました。^{[8] Simulaは、}クラスとオブジェクト、継承、動的バインディング など、今日のオブジェクト指向プログラミングに不可欠な重要な概念を導入しました。^{[10]オブジェクト指向のSimulaプログラミング言語は、主に}物理モデリング に携わる研究者によって使用されました。たとえば、貨物港を通る船舶とその内容物の動きを研究し、改善するためのモデルなどです。^[10]

MIT と Simula 言語の影響を受け、1966 年 11 月にAlan Kay は、最終的にSmalltalkプログラミング言語に組み込まれるアイデアに取り組み始めました。Kay は、1967 年にはすでに会話の中で「オブジェクト指向プログラミング」という用語を使用していました。^[1]「オブジェクト指向プログラミングの父」と呼ばれることもありますが、^{[11] Alan Kay は、OO の概念を、より一般的な}抽象データ型のオブジェクトの概念と区別し、コンピュータ サイエンスの権威が彼の概念を採用しなかったことを示唆しています。^[1] Barbara Liskov と共著した 1976 年の MIT メモでは、Simula 67、CLU、Alphard がオブジェクト指向言語として挙げられていますが、Smalltalk については触れられていません。 ^[12]

1970年代に、Smalltalkプログラミング言語の最初のバージョンが、 Xerox PARCでAlan Kay、Dan Ingalls、Adele Goldbergによって開発されました。Smalltalk-72にはプログラミング環境が含まれており、動的型付けされており、最初はコンパイルではなくインタープリタでした。Smalltalkは、言語レベルでのオブジェクト指向の適用とグラフィカルな開発環境で有名になりました。Smalltalkはさまざまなバージョンを経て、言語への関心が高まりました。^[13] SmalltalkはSimula 67で導入されたアイデアの影響を受けていまし たが、クラスを動的に作成および変更できる完全に動的なシステムとして設計されました。^[14]

1970年代後半から1980年代にかけて、オブジェクト指向プログラミングが注目を集めるようになった。1979年に開発が始まったFlavorsオブジェクト指向Lispでは、多重継承とミックスインが導入された。^[15] 1981年、ゴールドバーグはByte Magazineの8月号を編集し、Smalltalkとオブジェクト指向プログラミングを幅広い読者に紹介した。^[16] Interlisp -DのオブジェクトシステムであるLOOPSはSmalltalkとFlavorsの影響を受けており、1982年にはそれに関する論文が発表された。^[17] 1986年、Association for Computing Machineryは、オブジェクト指向プログラミング、システム、言語、およびアプリケーションに関する第1回会議（OOPSLA）を開催し、1,000人が参加した。その他の開発の中には、関数型プログラミングとオブジェクト指向プログラミングを統合し、メタオブジェクトプロトコルによる拡張を可能にするCommon Lispオブジェクトシステムがあった。 1980 年代には、メモリ内のオブジェクトに対するハードウェア サポートを含むプロセッサ アーキテクチャを設計する試みがいくつかありましたが、これらは成功しませんでした。例としては、Intel iAPX 432やLinn Smart Rekursiv などがあります。

1980年代半ば、Objective-Cは、 ITT社でSmalltalkを使用していたBrad Coxによって開発されました。博士論文にSimulaを使用していたBjarne Stroustrupは、オブジェクト指向のC++を作成しました。^[13] 1985年には、Bertrand MeyerもEiffel言語の最初の設計を作成しました。ソフトウェアの品質に焦点を当てたEiffelは、純粋なオブジェクト指向プログラミング言語であり、ソフトウェアライフサイクル全体をサポートする表記法です。Meyerは、オブジェクト指向ソフトウェア構築で、ソフトウェアエンジニアリングとコンピューターサイエンスからのいくつかの重要なアイデアに基づいたEiffelソフトウェア開発手法について説明しました。^[18] Eiffelの品質重視に不可欠なのは、Meyerの信頼性メカニズムである契約による設計であり、これは手法と言語の両方に不可欠な部分です。

1990年代前半から中頃にかけて、オブジェクト指向プログラミングは、その手法をサポートするプログラミング言語が広く普及するにつれて、主要なプログラミングパラダイムとして発展しました。これらには、 Visual FoxPro 3.0、^{[19] [20]} C++、^[21]およびDelphi ^{[要出典]が含まれます。オブジェクト指向プログラミング手法に大きく依存する}グラフィカルユーザーインターフェイスの人気の高まりにより、その優位性はさらに高まりました。密接に関連した動的GUIライブラリとOOP言語の例は、Mac OS XのCocoaフレームワークにあります。これは、Smalltalkに基づくCのオブジェクト指向の動的メッセージング拡張であるObjective-Cで記述されています。OOPツールキットは、イベント駆動型プログラミングの人気も高めました（ただし、この概念はOOPに限定されません）。

ETH チューリッヒでは、ニクラウス・ヴィルトと彼の同僚がモジュール境界を越えた型チェックの概念を調査しました。Modula -2 (1978) にはこの概念が組み込まれ、その後の設計であるOberon (1987) にはオブジェクト指向、クラスなどに対する独特のアプローチが組み込まれました。ヴィルトの設計では、継承は明らかではありません。彼の命名法は逆方向を指しているからです。継承は型拡張と呼ばれ、視点は親から継承者へと向かいます。

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

最近では、主にオブジェクト指向でありながら、手続き型方法論とも互換性のある言語がいくつか登場しています。そのような言語として、PythonとRubyがあります。最近のオブジェクト指向言語の中でおそらく最も商業的に重要なものは、Sun Microsystemsが開発したJavaと、Microsoft の.NETプラットフォーム用に設計されたC#およびVisual Basic.NET (VB.NET) です。これら 2 つのフレームワークはそれぞれ、実装から抽象化を作成することで、OOP を使用する利点を独自の方法で示しています。VB.NET と C# は言語間の継承をサポートしており、1 つの言語で定義されたクラスを、他の言語で定義されたクラスのサブクラスにすることができます。

オブジェクト指向プログラミングではオブジェクトを使用しますが、OOP をサポートすると主張する言語では、関連するテクニックや構造のすべてが直接サポートされているわけではありません。以下に挙げる機能は、クラス指向およびオブジェクト指向が強い (またはOOP をサポートするマルチパラダイム) と見なされる言語に共通していますが、注目すべき例外もいくつかあります。 ^{[22] [23] [24] [25]} Christopher J. Date は、OOP と他のテクノロジー、特にリレーショナル テクノロジーとの批判的な比較は、OOP の合意された厳密な定義がないため難しいと述べています。^[26]

• 整数や英数字などの少数の組み込みデータ型でフォーマットされた情報を格納できる変数。これには、組み込みまたはメモリ ポインタを使用して変数を組み合わせた結果の文字列、リスト、ハッシュ テーブルなどのデータ構造が含まれる場合があります。
• プロシージャ (関数、メソッド、ルーチン、サブルーチンとも呼ばれる) は、入力を受け取り、出力を生成し、データを操作します。最新の言語には、ループや条件文などの構造化プログラミング構造が含まれています。

モジュラー プログラミングサポートにより、整理のためにプロシージャをファイルとモジュールにグループ化できます。モジュールは名前空間化されているため、あるモジュールの識別子が、別のファイルまたはモジュールで同じ名前を共有するプロシージャまたは変数と競合することはありません。

オブジェクトは、フィールド(データを含む状態変数) とメソッド(コード内でオブジェクトの動作を定義するサブルーチンまたはプロシージャ) を含むデータ構造または抽象データ型です。フィールドは、メンバー、属性、またはプロパティとも呼ばれます。オブジェクトは通常、連続したメモリ領域として保存されます。オブジェクトは、複雑な内部構造を持つ変数のようにアクセスされ、多くの言語では実質的にポインターであり、ヒープまたはスタック内のメモリにあるオブジェクトの単一のインスタンスへの実際の参照として機能します。

オブジェクトは、現実世界にある物に対応することもあります。^[27]たとえば、グラフィックス プログラムには、「円」、「四角形」、「メニュー」などのオブジェクトがあります。オンライン ショッピング システムには、「ショッピング カート」、「顧客」、「製品」などのオブジェクトがあります。開いているファイルを表すオブジェクトや、米国慣用単位からメートル法への計測値の変換サービスを提供するオブジェクトなど、オブジェクトはより抽象的なエンティティを表すこともあります。

オブジェクトは、インスタンス変数に他のオブジェクトを含めることができます。これは、オブジェクト合成と呼ばれます。たとえば、Employee クラスのオブジェクトには、"first_name" や "position" などの独自のインスタンス変数に加えて、Address クラスのオブジェクトが (直接またはポインターを介して) 含まれる場合があります。オブジェクト合成は、「has-a」関係を表すために使用されます。すべての従業員には住所があるため、すべての Employee オブジェクトは、Address オブジェクトを格納する場所 (それ自体に直接埋め込まれているか、ポインターを介してアドレス指定された別の場所) にアクセスできます。Date と Darwen は、RDBMS をサポートするためにOOP を一種のカスタマイズ可能な型システムとして使用する理論的基礎を提案しましたが、オブジェクト ポインターは禁止されています。^[28]

OOPパラダイムは、ソフトウェア設計とモデリングにおけるオブジェクトの使用を過度に重視し、他の重要な側面（計算/アルゴリズム）を犠牲にしていると批判されてきた。^{[29] [30]}たとえば、Rob Pikeは、OOP言語はデータ構造とアルゴリズムから型に重点を移すことが多いと述べている。^[31] Steve Yeggeは、関数型プログラミングとは対照的に、次のように指摘している。^[32]

オブジェクト指向プログラミングでは、名詞が何よりも優先されます。なぜ、品詞を重要視するためにそこまでするのでしょうか。なぜ、ある概念が他の概念よりも優先されるのでしょうか。OOP によって、私たちが実際に考える方法において、動詞の重要性が突然低下したわけではありません。これは奇妙に歪んだ見方です。

Clojureの作者であるリッチ・ヒッキーは、オブジェクトシステムは現実世界の過度に単純化されたモデルであると述べました。彼は、OOPが時間を適切にモデル化できないことを強調しました。これは、ソフトウェアシステムがより並行的になるにつれてますます問題になっています。^[30]

アレクサンダー・ステパノフは、オブジェクト指向をジェネリックプログラミングと比較して不利な立場に立たせている。^[29]

OOP は技術的に不健全だと思います。OOP は、単一の型で変化するインターフェースの観点から世界を分解しようとします。実際の問題に対処するには、マルチソート代数 (複数の型にまたがるインターフェースのファミリー) が必要です。OOP は哲学的に不健全だと思います。OOP は、すべてがオブジェクトであると主張します。たとえそれが真実だとしても、あまり興味深いことではありません。すべてがオブジェクトであると言うことは、何も言っていないことになります。

OOP 言語は多様ですが、通常、OOP 言語では、クラスまたはプロトタイプの形式でコードの再利用と拡張性のために継承が許可されます。これらの継承形式は大きく異なりますが、オブジェクトとインスタンスの概念を定義するために類似の用語が使用されます。

最も一般的なスタイルであるクラスベースのプログラミングでは、各オブジェクトは特定のクラスのインスタンスである必要があります。クラスは、特定の型またはクラスのオブジェクトに対して、データ形式または型(メンバー変数とその型を含む) と利用可能なプロシージャ (クラス メソッドまたはメンバー関数) を定義します。オブジェクトは、クラス内のコンストラクターと呼ばれる特別な型のメソッドを呼び出すことによって作成されます。クラスは他のクラスから継承できるため、クラスは「is-a-type-of」関係を表す階層に配置されます。たとえば、クラス Employee はクラス Person から継承する場合があります。親クラスで利用可能なすべてのデータとメソッドは、同じ名前で子クラスにも表示されます。たとえば、クラス Person は、メソッド「make_full_name()」を使用して変数「first_name」と「last_name」を定義する場合があります。これらはクラス Employee でも利用可能で、クラスでは変数「position」と「salary」が追加される可能性があります。クラス Employee のすべてのインスタンスは、名前、ポジション、給与など、同じ変数を持つことが保証されます。プロシージャと変数は、クラスまたはインスタンスに固有のものにすることができます。これにより、次の用語が導き出されます。

• クラス変数–クラス全体に属します。各変数のコピーは 1 つだけ存在し、クラスのすべてのインスタンスで共有されます。
• インスタンス変数または属性 – 個々のオブジェクトに属するデータ。各オブジェクトにはそれぞれのコピーが存在します。上記の 4 つの変数 (first_name、position など) はすべてインスタンス変数です。
• メンバー変数– 特定のクラスによって定義されるクラス変数とインスタンス変数の両方を指します。
• クラスメソッド –クラス全体に属し、クラス変数とプロシージャ呼び出しからの入力にのみアクセスできます。
• インスタンスメソッド –個々のオブジェクトに属し、呼び出される特定のオブジェクトのインスタンス変数、入力、クラス変数にアクセスできます。

言語の定義に応じて、サブクラスはスーパークラスで定義されたメソッドをオーバーライドできる場合とできない場合があります。一部の言語では多重継承が許可されていますが、オーバーライドの解決が複雑になることがあります。一部の言語では、特性やミックスインなどの他の概念が特別にサポートされていますが、多重継承のある言語では、ミックスインは単に is-a-type-of 関係を表さないクラスです。ミックスインは通常、複数のクラスに同じメソッドを追加するために使用されます。たとえば、クラス UnicodeConversionMixin は、共通の親を共有しないクラス FileReader とクラス WebPageScraper に含まれている場合、メソッド unicode_to_ascii() を提供する場合があります。

抽象クラスはオブジェクトにインスタンス化できません。インスタンス化できる他の「具体的な」クラスへの継承のためだけに存在します。Javaでは、finalキーワードを使用してクラスがサブクラス化されるのを防ぐことができます。^[33]

対照的に、プロトタイプベースのプログラミングでは、オブジェクトが主要なエンティティです。一般に、「クラス」という概念は存在しません。むしろ、オブジェクトのプロトタイプまたは親は、オブジェクトがリンクされている別のオブジェクトにすぎません。Self では、オブジェクトは複数の親を持つことも、親を持たないこともありますが、^[34]最も普及しているプロトタイプベースの言語である Javascript では、すべてのオブジェクトにプロトタイプリンクが 1 つ (1 つだけ) あります。新しいオブジェクトは、プロトタイプとして選択された既存のオブジェクトに基づいて作成できます。オブジェクトfruitが存在し、appleとorange の両方がプロトタイプとしてfruit を持っている場合、2 つの異なるオブジェクトappleとorange をfruit と呼ぶことができます。fruit クラスの概念は明示的には存在しませんが、同じプロトタイプを共有するオブジェクトの同値クラスとして、または特定のインターフェイスを満たすオブジェクトのセット (ダック タイピング) としてモデル化できます。クラスベースのプログラミングとは異なり、プロトタイプベースの言語では通常、他のオブジェクトと共有されない属性とメソッドを定義できます。たとえば、属性sugar_content はappleでは定義できますが、orangeでは定義できません。

Goのような言語は継承をまったくサポートしていません。Goはオブジェクト指向であると述べており、^[35] C++の作者であるBjarne Stroustrupは継承なしでOOPを行うことが可能であると述べています。^[36]継承よりも構成の原則は、継承の代わりに構成を使用してhas-a関係を実装することを提唱しています。たとえば、クラスPersonから継承する代わりに、クラスEmployeeは各Employeeオブジェクトに内部Personオブジェクトを与えることができます。そうすれば、クラスPersonに多くのパブリック属性やメソッドがあっても、外部コードからそのオブジェクトを隠すことができます。委任は、継承の代替として使用できる別の言語機能です。

ロブ・パイクは、 3行のルックアップテーブルよりも階層化された抽象化による多段階の型階層を好むとして、オブジェクト指向の考え方を批判した。^[37]彼はオブジェクト指向プログラミングを「コンピューティングのローマ数字」と呼んだ。^[38]

ボブ・マーティンは、関連するクラスはソフトウェアであるため、必ずしもそれらが表すものの関係を共有するわけではないと述べています。^[39]

メソッド呼び出しに応じて実行する手続き型コードを選択するのは、外部コードではなくオブジェクトの責任であり、通常は実行時にオブジェクトに関連付けられたテーブルでメソッドを検索することによって行われます。この機能は、動的ディスパッチと呼ばれます。呼び出しの可変性が、呼び出し先のオブジェクトの 1 つ以上のタイプに依存する場合 (つまり、メソッドの選択に少なくとも 1 つの他のパラメーター オブジェクトが関係する場合)、多重ディスパッチと呼ばれます。メソッド呼び出しは、メッセージ パッシングとも呼ばれます。これは、ディスパッチのためにオブジェクトに渡されるメッセージ (メソッドの名前とその入力パラメーター) として概念化されます。

ディスパッチは継承と相互作用します。特定のオブジェクトまたはクラスにメソッドが存在しない場合、ディスパッチはその親オブジェクトまたはクラスに委任され、継承チェーンを上っていきます。

データ抽象化は、データが意味的に関連する関数にのみ見えるようにして、誤用を防ぐ設計パターンです。データ抽象化の成功により、オブジェクト指向プログラミングや純粋関数型プログラミングの設計原則として、データの隠蔽が頻繁に取り入れられるようになりました。同様に、カプセル化により、外部コードがオブジェクトの内部動作に関与することがなくなります。これにより、コードのリファクタリングが容易になり、たとえば、クラスの作成者は、外部コードを変更せずに、そのクラスのオブジェクトが内部でデータを表す方法を変更できます (「パブリック」メソッド呼び出しが同じように機能する限り)。また、特定のデータセットに関係するすべてのコードを同じクラスに配置するようにプログラマーが促され、他のプログラマーが簡単に理解できるように整理されます。カプセル化は、分離を促進する手法です。

オブジェクト指向プログラミングでは、オブジェクトは、内部コードと外部コードを分離し、抽象化とカプセル化を実装するために使用できるレイヤーを提供します。外部コードは、特定のインスタンスメソッドを特定の入力パラメータセットで呼び出したり、インスタンス変数を読んだり、インスタンス変数に書き込んだりすることによってのみ、オブジェクトを使用できます。プログラムは実行時にオブジェクトのインスタンスを多数作成し、それらは独立して動作します。この手法により、異なるデータセットに対して同じ手順とデータ定義を簡単に再利用できるだけでなく、現実世界の関係を直感的に反映できる可能性があると言われています。開発者は、データベーステーブルやプログラミングサブルーチンを使用するのではなく、ユーザーがより使い慣れているオブジェクト、つまりアプリケーションドメインのオブジェクトを使用します。^[40] OOPパラダイムが再利用性とモジュール性を高めるというこれらの主張は批判されています。^{[41] [42]}

初期設計では、ローカル（またはメソッド）変数、プライベート変数（オブジェクト指向プログラミングの場合）、グローバル（またはパブリック）変数の順に、可能な限り最も制限された可視性を使用し、必要な場合にのみ拡張することが推奨されます。これにより、可視性の変更によって既存のコードが無効になることを防ぎます。^[43]

クラスが呼び出しコードによる内部オブジェクトデータへのアクセスを許可せず、メソッド経由のアクセスのみを許可する場合も、情報隠蔽の一種です。一部の言語（Javaなど）では、クラスがアクセス制限を明示的に適用できます。たとえば、privateキーワードを使用して内部データを示し、キーワードを使用してクラス外のコードで使用するメソッドを指定しますpublic。^[44]メソッドは、public、private、またはprotected（同じクラスとそのサブクラスからのアクセスは許可するが、異なるクラスのオブジェクトからのアクセスは許可しない）などの中間レベルで設計することもできます。^[44]他の言語（Pythonなど）では、これは慣例によってのみ適用されます（たとえば、メソッドの名前はアンダースコアprivateで始まる場合があります）。C#、Swift、Kotlin言語では、キーワードは、クラスと同じアセンブリ、パッケージ、またはモジュールにあるファイルへのアクセスのみを許可します。^[45]internal

プログラミング言語、特にオブジェクト指向言語では、抽象化を重視することが極めて重要です。オブジェクト指向言語は、型の概念を拡張してデータ抽象化を組み込み、メソッドを通じて内部データへのアクセスを制限することの重要性を強調しています。^[46] Eric S. Raymondは、オブジェクト指向プログラミング言語は、透明性を損なう厚い階層のプログラムを促進する傾向があると書いています。 [47] Raymond は、これを Unix やC プログラミング言語で採用されているアプローチと比較して不利な点があるとしています。^{[ 47]}

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

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

レオ・ブロディは、オブジェクトのスタンドアロン性と、ソフトウェア開発の「同じことを繰り返さない」原則[49]に違反してコードを重複させる傾向^{[ 48]}との間に関連性があると示唆している。

サブタイピング(ポリモーフィズムの一形態) とは、呼び出しコードが、サポートされている階層内のどのクラス (親クラスまたはその子孫のいずれか) で操作しているかに関係なく実行できることを意味します。一方、継承階層内のオブジェクト間で同じ操作名が異なる動作をする場合があります。

たとえば、Circle 型と Square 型のオブジェクトは、Shape と呼ばれる共通クラスから派生しています。Shape の各型の Draw 関数は、それ自体を描画するために必要なものを実装しますが、呼び出しコードは、描画される Shape の特定の型には無関係なままです。

これは、クラス階層の外部のコードを簡素化し、強力な関心の分離を可能にする別のタイプの抽象化です。

オブジェクトの一般的な特徴は、メソッドがオブジェクトにアタッチされており、オブジェクトのデータ フィールドにアクセスして変更できることです。この種類の OOP では、通常、現在のオブジェクトを参照するために使用されるthisまたはなどの特別な名前があります。オープン再帰をselfサポートする言語では、オブジェクト メソッドはこの名前を使用して、同じオブジェクト (自分自身を含む) の他のメソッドを呼び出すことができます。この変数は遅延バインディングです。つまり、あるクラスで定義されたメソッドが、そのサブクラスで後で定義された別のメソッドを呼び出すことができます。

Simula (1967)は、オブジェクト指向言語の主要な機能を備えた最初の言語として一般に認められています。これはシミュレーション プログラムを作成するために作成され、オブジェクトと呼ばれるものが最も重要な情報表現でした。Smalltalk (1972 ～ 1980) も初期の例の 1 つであり、OOP の理論の多くがこれに基づいて開発されました。オブジェクト指向の程度に関しては、次の区別ができます。

• これらの言語は、文字や句読点などのプリミティブから、クラス、プロトタイプ、ブロック、モジュールなど全体に至るまで、すべてが一貫してオブジェクトとして扱われるため、「純粋な」オブジェクト指向言語と呼ばれます。これらの言語は、オブジェクト指向メソッドを容易にし、さらに強制するように特別に設計されています。例: Ruby、Scala、Smalltalk、Eiffel、Emerald、^[50] JADE、Self、Raku。
• 主にオブジェクト指向プログラミング用に設計された言語ですが、いくつかの手続き型要素も備えています。例: Java、Python、C++、C#、Delphi / Object Pascal、VB.NET。
• 歴史的には手続き型言語ですが、いくつかの OO 機能が拡張されている言語。例: PHP、JavaScript、Perl、Visual Basic (BASIC から派生)、MATLAB、COBOL 2002、Fortran 2003、ABAP、Ada 95、Pascal。
• オブジェクトの機能 (クラス、メソッド、継承) のほとんどを備えていますが、明確に独自の形式になっている言語。例: Oberon (Oberon-1 または Oberon-2)。
• 抽象データ型のサポートを備えた言語。OO プログラミングに似せて使用できますが、オブジェクト指向のすべての機能はありません。これには、オブジェクトベース言語とプロトタイプベース言語が含まれます。例: JavaScript、Lua、Modula-2、CLU。
• OO を含む複数のパラダイムをサポートするカメレオン言語。Tclは、プロトタイプベースのプログラミングとクラスベースの OO の両方をサポートするハイブリッド オブジェクト システムである TclOO によって、これらの言語の中でも際立っています。

C++、Java、Python など、広く使用されている多くの言語は、オブジェクト指向機能を備えています。過去にはオブジェクト指向プログラミングが広く受け入れられていましたが、^{[51]最近では、オブジェクト指向プログラミングを批判し、これらの機能を避けることを推奨する (一般的に}関数型プログラミングを支持する) エッセイが開発者コミュニティで非常に人気があります。^[52] ポール グラハムは、大企業での OOP の人気は、「大規模な (そして頻繁に入れ替わる) 凡庸なプログラマーのグループ」によるものだと示唆しています。グラハムによると、OOP によって課せられた規律により、1 人のプログラマーが「大きな損害を与える」ことが防止されます。^[53] Unixプログラマーであり、オープンソース ソフトウェアの支持者であるエリック S. レイモンドは、オブジェクト指向プログラミングを「唯一の真の解決策」として提示する主張に批判的です。^[47]

リチャード・フェルドマンは、これらの言語はオブジェクト指向機能を追加することでモジュール性が向上したかもしれないが、オブジェクト指向であること以外の理由で人気が高まったと主張している。^[54]ローレンス・クルブナーは記事の中で、他の言語（LISP方言、関数型言語など）と比較して、OOP言語には独自の強みがなく、不必要な複雑さの重荷を負わせていると主張した。^[55]ポトクらによる研究では、OOPと手続き型アプローチの生産性に大きな違いは見られなかった。^[56] ルカ・カルデッリは、OOPコードは手続き型コードよりも「本質的に効率が悪い」ため、OOPのコンパイルには時間がかかる可能性があると主張している。^[41]

近年、オブジェクト指向プログラミングは、動的プログラミング言語で特に人気が高まっています。Python 、PowerShell、Ruby、Groovy はOOPの原則に基づいて構築された動的言語であり、PerlとPHP はPerl 5 と PHP 4 以降、 ColdFusion はバージョン 6 以降 、オブジェクト指向機能を追加しています。

インターネット上のHTML、XHTML、およびXMLドキュメントのドキュメントオブジェクト モデルには、一般的なJavaScript / ECMAScript言語へのバインディングがあります。 JavaScript はおそらく最もよく知られているプロトタイプ ベースのプログラミング言語で、クラスから継承するのではなくプロトタイプから複製します (クラス ベースのプログラミングとは対照的)。 このアプローチを採用している別のスクリプト言語はLuaです。

クライアント サーバー環境でサービスを要求するためにコンピューター間でやり取りされるメッセージは、クライアントとサーバーの両方に知られているクラス オブジェクトによって定義されたオブジェクトの線形化として設計できます。たとえば、単純な線形化オブジェクトは、長さフィールド、クラスを識別するコード ポイント、およびデータ値で構成されます。より複雑な例としては、コマンドの長さとコード ポイントで構成されるコマンドと、コマンドのパラメーターを表す線形化オブジェクトで構成される値があります。このような各コマンドは、サーバーによって、そのクラス (またはスーパークラス) がコマンドを認識し、要求されたサービスを提供できるオブジェクトに送信される必要があります。クライアントとサーバーは、複雑なオブジェクト指向構造としてモデル化するのが最適です。分散データ管理アーキテクチャ(DDM) はこのアプローチを採用し、クラス オブジェクトを使用して、形式的な階層の 4 つのレベルでオブジェクトを定義します。

• 長さ、コード ポイント、データ値など、メッセージを形成するデータ値を定義するフィールド。
• Smalltalkプログラムのメッセージやパラメータに見られるものと類似したオブジェクトおよびオブジェクトのコレクション。
• IBM i オブジェクトに似たマネージャー。たとえば、ファイルへのディレクトリーや、メタデータとレコードで構成されるファイルなどです。マネージャーは概念的に、含まれるオブジェクトにメモリと処理リソースを提供します。
• ディレクトリ サービス、セキュリティ、同時実行制御などの側面をサポートする、完全な処理環境を実装するために必要なすべてのマネージャーで構成されるクライアントまたはサーバー。

DDM の初期バージョンでは、分散ファイル サービスが定義されていました。これは後に拡張され、分散リレーショナル データベース アーキテクチャ(DRDA)の基盤となりました。

オブジェクト指向設計の課題に対処する 1 つの方法は、ソフトウェア設計でよく発生する問題に対するソリューション パターンであるデザイン パターンを使用することです。これらのよく発生する問題の中には、オブジェクト指向開発に特有の影響とソリューションを持つものがあります。

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

• 関数オブジェクト: 単一のメソッド(C++では関数演算子operator())を持ち、関数のように動作します。

• 不変オブジェクト: 作成後に状態は変化しません

• ファーストクラスオブジェクト：制限なく使用可能

• コンテナオブジェクト: 他のオブジェクトを含む

• ファクトリーオブジェクト:他のオブジェクトを作成する

• メタオブジェクト: 他のオブジェクトを作成できるもの(必ずしもオブジェクトではないクラスと比較)

• プロトタイプオブジェクト: コピーすることで他のオブジェクトを作成できる特殊なメタオブジェクト

• シングルトンオブジェクト: プログラムの存続期間中、そのクラスの唯一のインスタンス

• フィルターオブジェクト: 入力としてデータストリームを受け取り、それをオブジェクトの出力に変換します。

オブジェクトのアンチパターンの例として、God オブジェクトは、知っていることや実行することが多すぎます。

継承によって意味的な「is a 」関係が作成されると考えるのは直感的であり、したがって、サブクラスからインスタンス化されたオブジェクトは、スーパークラスからインスタンス化されたオブジェクトの代わりに常に安全に使用できると推論できます。残念ながら、この直感はほとんどの OOP 言語、特に可変オブジェクトを許可するすべての言語では誤りです。可変オブジェクトを使用する OOP 言語の型チェッカーによって強制されるサブタイプ多態性は、どのようなコンテキストでも動作のサブタイプ化を保証することはできません。動作のサブタイプ化は一般に決定不可能であるため、プログラム (コンパイラ) によって実装することはできません。クラスまたはオブジェクトの階層は、構文的に検出できない誤った使用の可能性を考慮して、慎重に設計する必要があります。この問題は、リスコフの置換原則として知られています。

『デザイン パターン: 再利用可能なオブジェクト指向ソフトウェアの要素』は、1994 年にErich Gamma、 Richard Helm、 Ralph Johnson、 John Vlissides (よく「Gang of Four」として冗談で呼ばれる) によって出版された影響力のある書籍です。オブジェクト指向プログラミングの機能と落とし穴を探求するとともに、23 の一般的なプログラミングの問題と、それらを解決するためのパターンについて説明します。

この本では以下のパターンについて説明しています。

• 創造パターン（5）：ファクトリメソッドパターン、抽象ファクトリパターン、シングルトンパターン、ビルダーパターン、プロトタイプパターン
• 構造パターン（7）：アダプタパターン、ブリッジパターン、コンポジットパターン、デコレータパターン、ファサードパターン、フライウェイトパターン、プロキシパターン
• 動作パターン（11）：責任連鎖パターン、コマンドパターン、インタープリタパターン、イテレータパターン、メディエーターパターン、、オブザーバパターン、状態パターン、戦略パターン、テンプレートメソッドパターン、ビジターパターン

オブジェクト指向プログラミングとリレーショナルデータベース管理システム(RDBMS) はどちらも、今日のソフトウェアでは非常に一般的です^[update]。リレーショナルデータベースはオブジェクトを直接保存しないため (一部の RDBMS にはこれを近似するオブジェクト指向機能がありますが)、2 つの世界の橋渡しをする必要があります。オブジェクト指向プログラミングのアクセスとデータパターンをリレーショナルデータベースに橋渡しする問題は、オブジェクトリレーショナルインピーダンスミスマッチとして知られています。この問題に対処するためのアプローチはいくつかありますが、欠点のない一般的な解決策はありません。^[58]最も一般的なアプローチの 1 つは、 Visual FoxProなどのIDE言語や、 Java Data ObjectsやRuby on Railsの ActiveRecordなどのライブラリに見られるオブジェクトリレーショナルマッピングです。

RDBMS の代わりに使用できる オブジェクト データベースもありますが、これらは技術的にも商業的にも RDBMS ほど成功していません。

OOP は、現実世界のオブジェクトやプロセスをデジタルの対応物と関連付けるために使用できます。ただし、OOP が直接現実世界のマッピングを容易にすることや、現実世界のマッピングが価値のある目標であることに誰もが同意するわけではありません。Bertrand Meyer は、オブジェクト指向ソフトウェア構築で、プログラムは世界のモデルではなく、世界の一部のモデルであると主張しています。「現実は二度離れたいとこです。」^[59]同時に、OOP の主な制限がいくつか指摘されています。^[60] たとえば、円と楕円の問題は、 OOP の継承の概念を使用して処理するのが困難です。

しかし、ニクラウス・ヴィルト（ヴィルトの法則として知られる格言「ソフトウェアはハードウェアが高速化するよりも急速に遅くなる」を広めた人物）は、論文「鏡を通して見る良いアイデア」の中で、OOPについて「このパラダイムは現実世界のシステムの構造を厳密に反映しているため、複雑な動作をする複雑なシステムをモデル化するのに適している」と述べています^[61] （KISS原則とは対照的）。

スティーブ・イェッゲらは、自然言語には、物事（オブジェクト/名詞）をアクション（メソッド/動詞）よりも厳密に優先するというOOPアプローチが欠けていると指摘した。 ^[62]この問題により、OOPは手続き型プログラミングよりも複雑な解決策を必要とする可能性がある。^[63]

OOPはソースコードの再利用性と保守性を高めるために開発されました。^[64]制御フローの透過的な表現は優先度が低く、コンパイラによって処理されることが想定されていました。並列ハードウェアとマルチスレッドコーディングの重要性が高まるにつれて、透過的な制御フローの開発がより重要になりますが、これはOOPでは実現が難しいことです。^{[65] [66] [67] [68]}

責任駆動設計では、クラスを契約の観点から定義します。つまり、クラスは責任とそれが共有する情報を中心に定義する必要があります。これは、Wirfs-Brock と Wilkerson によって、保持する必要があるデータ構造を中心にクラスが定義されるデータ駆動設計と対比されています。著者は、責任駆動設計の方が望ましいと考えています。

SOLIDは Michael Feathers によって考案された 5 つのソフトウェア エンジニアリング設計原則を表す記憶術です。

• 単一責任の原則
• オープン/クローズド原則
• リスコフの置換原理
• インターフェース分離の原則
• 依存性逆転の原則

GRASP (General Responsibility Assignment Software Patterns) は、Craig Larmanが提唱するもう 1 つのガイドライン セットです。

オブジェクトは、オブジェクト指向システムにおける実行時のエンティティです。オブジェクトは、人、場所、銀行口座、データ テーブル、またはプログラムが処理する必要がある任意の項目を表します。

オブジェクト指向プログラミングで使用される概念を形式化する試みはいくつか行われてきました。次の概念と構成が、OOP 概念の解釈として使用されてきました。

• 代数的データ型^[69]
• 再帰型
• カプセル化された状態
• 継承
• レコードは、関数リテラルをフィールドに格納できる場合（関数型プログラミング言語のように）、オブジェクトを理解するための基礎となるが、実際の計算はOOPの本質的な機能を組み込むためにかなり複雑になる必要がある。可変オブジェクトを扱うSystem F _<:のいくつかの拡張が研究されてきた。^[70]これらはサブタイプ多態性とパラメトリック多態性（ジェネリック）の両方を可能にする。

オブジェクトの背後にある合意された定義や理論を見つけようとする試みはあまり成功していない (ただし、多くの OOP 概念と構成の正式な定義については、Abadi & Cardelli の「オブジェクトの理論^」[70]を参照) し、多くの場合、大きく異なる。たとえば、一部の定義は精神的な活動に焦点を当てており、他の定義はプログラム構造に焦点を当てている。より単純な定義の 1 つは、OOP は「マップ」データ構造または配列を使用する行為であり、関数や他のマップへのポインターを含めることができ、すべてに構文とスコープの糖衣が加えられているというものである。継承は、マップを複製することによって実行できる (「プロトタイピング」と呼ばれることもある)。

• ケーデス
• 共通オブジェクトリクエストブローカーアーキテクチャ(CORBA)
• 分散コンポーネントオブジェクトモデル
• 分散データ管理アーキテクチャ
• ジェルー

• IDEF4
• インターフェース記述言語
• UMLS とは

• プログラミング言語の比較（オブジェクト指向プログラミング）
• コンポーネントベースのソフトウェアエンジニアリング
• オブジェクトの関連付け
• オブジェクトモデリング言語
• オブジェクト指向分析と設計
• オブジェクト指向オントロジー

• マーティン・アバディ;ルカ・カルデッリ(1998)。オブジェクトの理論。スプリンガー・フェルラーグ。ISBN 978-0-387-94775-4。
• アベルソン、ハロルド、ジェラルド・ジェイ・サスマン（1997年）。コンピュータプログラムの構造と解釈。MITプレス。ISBN 978-0-262-01153-2. 2017年12月26日時点のオリジナルよりアーカイブ。2006年1月22日閲覧。
•  Armstrong , Deborah J. (2006 年 2 月)。「オブジェクト指向開発のクォーク」。Communications of the ACM。49 ( 2): 123–128。doi : 10.1145 /1113034.1113040。ISSN 0001-0782。S2CID 11485502  。
• Bloch, Joshua (2018)。『Effective Java: プログラミング言語ガイド』（第 3 版）。Addison- Wesley。ISBN 978-0134685991。
• ブーチ、グレイディ(1997)。『オブジェクト指向分析と設計とその応用』。Addison - Wesley。ISBN 978-0-8053-5340-2。
• イールズ、ピーター、オリバー・シムズ(1998)。『ビジネスオブジェクトの構築』。ジョン・ワイリー・アンド・サンズ。ISBN 978-0-471-19176-6。
• ガンマ、エリック、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシデス(1995)。デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの要素。Addison-Wesley。Bibcode : 1995dper.book..... G。ISBN 978-0-201-63361-0。
• ハーモン、ポール、ウィリアム・モリッシー（1996）。オブジェクトテクノロジーケースブック - 受賞歴のあるビジネスアプリケーションからの教訓。ジョン・ワイリー＆サンズ。ISBN 978-0-471-14717-6。
• Jacobson, Ivar (1992)。オブジェクト指向ソフトウェアエンジニアリング: ユースケース駆動型アプローチ。Addison -Wesley。Bibcode :1992oose.book.....J. ISBN 978-0-201-54435-0。
• Kay, Alan . Smalltalk の初期の歴史。2005 年 4 月 4 日時点のオリジナルよりアーカイブ。2005 年4 月 18 日閲覧。
• マイヤー、バートランド(1997)。オブジェクト指向ソフトウェア構築。プレンティス ホール。ISBN 978-0-13-629155-8。
• Pecinovsky, Rudolf (2013)。OOP – オブジェクト指向の考え方とプログラミングを学ぶ。Bruckner Publishing。ISBN 978-80-904661-8-0。
• ラムボー、ジェームズ、マイケル・ブラハ、ウィリアム・プレメラニ、フレデリック・エディ、ウィリアム・ロレンセン (1991)。オブジェクト指向モデリングと設計。プレンティス・ホール。ISBN 978-0-13-629841-0。
• Schach, Stephen (2006)。『オブジェクト指向と古典的ソフトウェア工学、第 7 版』。McGraw - Hill。ISBN 978-0-07-319126-3。
• シュライナー、アクセル・トビアス (1993)。ANSI-C を使用したオブジェクト指向プログラミング。ハンザー。hdl :1850/8544。ISBN 978-3-446-17426-9。
• テイラー、デビッド A. (1992)。オブジェクト指向情報システム - 計画と実装。ジョン ワイリー アンド サンズ。ISBN 978-0-471-54364-0。
• ワイスフェルド、マット (2009)。『オブジェクト指向の思考プロセス、第 3 版』。Addison - Wesley。ISBN 978-0-672-33016-2。
• West , David (2004)。オブジェクト思考 (開発者向けリファレンス) 。Microsoft Press。ISBN 978-0-7356-1965-4。

• オブジェクト指向プログラミングの概念 (OOP) などについての紹介 (LWC Nirosh 著)
• OOP の短所に関する議論
• OOP の概念 (Java チュートリアル)