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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

オブジェクト指向プログラミングOOP)は、 「オブジェクト」の概念に基づくプログラミングパラダイムであり、データコードを含めることができます。フィールド形式のデータ(多くの場合、属性またはプロパティと呼ばれます)と、プロシージャ形式のコードです。 (多くの場合、メソッドとして知られています)。

オブジェクトの特徴は、オブジェクト自体のプロシージャがそれ自体のデータフィールドにアクセスし、多くの場合それを変更できることです(オブジェクトにはまたはの概念がありますOOPでは、コンピュータープログラムは、相互作用するオブジェクトから作成することによって設計されます。[1] [2] OOP言語は多様ですが、最も人気のある言語はクラスベースです。つまり、オブジェクトはクラスのインスタンスであり、クラスのタイプも決定しますthisself

最も広く使用されているプログラミング言語(C ++、Java、Pythonなど)の多くはマルチパラダイムであり、オブジェクト指向プログラミングを多かれ少なかれサポートします。通常は、必須手続き型プログラミングと組み合わせて使用​​します。重要なオブジェクト指向言語には、 JavaC ++C#PythonRPHPVisual Basic.NETJavaScriptRubyPerlSIMSCRIPTObject PascalObjective-CDartが含まれます。SwiftScalaKotlinCommon LispMATLAB、および Smalltalk

歴史

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

オブジェクト指向プログラミングの現代的な意味での「オブジェクト」と「指向」を呼び出す用語は、1950年代後半から1960年代初頭にMITで最初に登場しました。人工知能グループの環境では、早くも1960年には、「オブジェクト」はプロパティ(属性)を持つ識別されたアイテム( LISPアトム)を指すことができました。[3] [4] Alan Kayは後に、1966年の彼の思考に強い影響を与えたとしてLISP内部の詳細な理解を引用しました。[5]

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

アラン・ケイ、[5]

もう1つの初期のMITの例は、1960〜 1961年にIvanSutherlandによって作成されたSketchpadでした。スケッチパッドに関する彼の論文に基づく1963年のテクニカルレポートの用語集で、サザーランドは、グラフィカルな相互作用に特化しているにもかかわらず、「オブジェクト」と「インスタンス」の概念を定義しました(クラスの概念は「マスター」または「定義」でカバーされています)。[6] また、MIT ALGOLバージョンのAED-0は、データ構造(その方言では「プレックス」)とプロシージャの間に直接リンクを確立し、後に「メッセージ」、「メソッド」、および「メンバー関数」と呼ばれるものを事前に設定しました。 "。[7] [8]

Simulaは、クラスオブジェクト、継承、動的バインディングなど、今日オブジェクト指向プログラミングの重要な部分である重要な概念を導入しました[9] オブジェクト指向のSimulaプログラミング言語は、主に、貨物港を通過する船の動きとその内容を研究および改善するためのモデルなど、物理モデリングに携わる研究者によって使用されました。[9]

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

1970年代、SmalltalkはLispコミュニティに影響を与え、 Lispマシンを介して開発者に導入されたオブジェクトベースの手法を取り入れましたLispのさまざまな拡張機能(多重継承ミックスインを導入するLOOPSやFlavoursなど)を試した結果、関数型プログラミングとオブジェクト指向プログラミングを統合し、メタオブジェクトプロトコルを介した拡張を可能にするCommon Lisp ObjectSystemが生まれました1980年代には、メモリ内のオブジェクトのハードウェアサポートを含むプロセッサアーキテクチャを設計する試みがいくつかありましたが、これらは成功しませんでした。例には、Intel iAPX432およびLinnSmartRekursiv

1981年、ゴールドバーグはByte Magazineの8月号を編集し、Smalltalkとオブジェクト指向プログラミングをより多くの視聴者に紹介しました。1986年に、Association for Computing Machineryは、オブジェクト指向プログラミング、システム、言語、およびアプリケーションに関する最初の会議(OOPSLA)を開催しました。この会議には、予想外に1,000人が参加しました。1980年代半ば、Objective-CはITTInc Smalltalkを使用していたBradCoxによって開発され、博士論文にSimulaを使用していたBjarneStroustrupは最終的にオブジェクト指向C ++を作成しました。[10] 1985年、バートランド・メイヤーエッフェル語の最初のデザインも制作しましたソフトウェアの品質に焦点を当てたEiffelは、純粋にオブジェクト指向のプログラミング言語であり、ソフトウェアのライフサイクル全体をサポートする表記法です。Meyerは、オブジェクト指向ソフトウェア構築で、ソフトウェアエンジニアリングとコンピュータサイエンスからの少数の重要なアイデアに基づいたEiffelソフトウェア開発方法について説明しましたEiffelの品質重視に不可欠なのは、Meyerの信頼性メカニズムであるDesign by Contractです。これは、メソッドと言語の両方に不可欠な部分です。

2002年から2018年までTIOBE プログラミング言語人気指数グラフ。2000年代には、オブジェクト指向Java(青)と手続き型 C(黒)がトップの座を争いました。

1990年代の初めと半ばに、技術をサポートするプログラミング言語が広く利用可能になったときに、主要なプログラミングパラダイムとしてオブジェクト指向プログラミングが開発されました。これらには、Visual FoxPro 3.0、[12] [13] [14] C ++[15]およびDelphi [要出典]が含まれていました。その優位性は、オブジェクト指向プログラミング技術に大きく依存するグラフィカルユーザーインターフェイスの人気の高まりによってさらに強化されました。密接に関連する動的GUIライブラリとOOP言語の例は、Mac OSXのCocoaフレームワークにありますObjective-C、Smalltalkに基づくCへのオブジェクト指向の動的メッセージング拡張。OOPツールキットは、イベント駆動型プログラミングの人気も高めました(ただし、この概念はOOPに限定されません)。

ETHチューリッヒではNiklaus Wirthと彼の同僚も、データの抽象化モジュラープログラミングなどのトピックを調査していました(ただし、これは1960年代以前に一般的に使用されていました)。Modula-2(1978)には両方が含まれ、その後の設計であるOberonには、オブジェクト指向やクラスなどへの独特のアプローチが含まれていました。

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

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

機能

オブジェクト指向プログラミングはオブジェクトを使用しますが、関連する技術と構造のすべてがOOPをサポートすると主張する言語で直接サポートされているわけではありません。オペランドに対して演算を実行します。以下にリストされている機能は、特筆すべき例外を除いて、クラス指向およびオブジェクト指向(またはOOPをサポートするマルチパラダイム)であると見なされる言語間で共通です。[16] [17] [18] [19]

非OOP言語と共有

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

オブジェクトとクラス

オブジェクト指向プログラミング(OOP)をサポートする言語は、通常、クラスまたはプロトタイプのいずれかの形式で、コードの再利用と拡張性のために継承を使用します。クラスを使用するものは、2つの主要な概念をサポートします。

  • クラス–特定のタイプまたはクラスのオブジェクトのデータ形式と使用可能なプロシージャの定義。データとプロシージャ(クラスメソッドと呼ばれる)自体も含まれる場合があります。つまり、クラスにはデータメンバーとメンバー関数が含まれます。
  • オブジェクト–クラスのインスタンス

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

各オブジェクトは特定のクラスのインスタンスであると言われます(たとえば、名前フィールドが「Mary」に設定されているオブジェクトは、クラスEmployeeのインスタンスである可能性があります)。オブジェクト指向プログラミングのプロシージャは、メソッドとして知られています。変数は、フィールド、メンバー、属性、またはプロパティとも呼ばれます。これにより、次の用語が使用されます。

  • クラス変数–クラス全体に属します; それぞれのコピーは1つだけです
  • インスタンス変数または属性–個々のオブジェクトに属するデータすべてのオブジェクトには、それぞれの独自のコピーがあります
  • メンバー変数–特定のクラスによって定義されたクラス変数とインスタンス変数の両方を指します
  • クラスメソッド–クラス全体に属し、クラス変数とプロシージャ呼び出しからの入力のみにアクセスできます
  • インスタンスメソッド–個々のオブジェクトに属し、呼び出された特定のオブジェクトのインスタンス変数、入力、およびクラス変数にアクセスできます

オブジェクトは、複雑な内部構造を持つ変数のようにアクセスされ、多くの言語では事実上ポインタであり、ヒープまたはスタック内のメモリ内のオブジェクトの単一インスタンスへの実際の参照として機能します。これらは、内部コードと外部コードを分離するために使用できる抽象化レイヤーを提供します。外部コードは、特定の入力パラメーターのセットを使用して特定のインスタンスメソッドを呼び出したり、インスタンス変数を読み取ったり、インスタンス変数に書き込んだりして、オブジェクトを使用できます。オブジェクトは、コンストラクターと呼ばれるクラスの特別なタイプのメソッドを呼び出すことによって作成されます。プログラムは、実行時に同じクラスのインスタンスを多数作成する場合があり、これらは独立して動作します。これは、同じ手順を異なるデータセットで使用するための簡単な方法です。

クラスを使用するオブジェクト指向プログラミングは、クラスベースプログラミングと呼ばれることもありますが、プロトタイプベースのプログラミングは通常、クラスを使用しません。その結果、オブジェクトインスタンスの概念を定義するために、大幅に異なるが類似した用語が使用されます

一部の言語では、クラスとオブジェクトは、トレイトミックスインなどの他の概念を使用して構成できます

クラスベースとプロトタイプベース

クラスベース言語では、クラスは事前に定義されており、オブジェクトクラスに基づいてインスタンス化されます。リンゴオレンジの2つのオブジェクトがFruitクラスからインスタンス化された場合、それらは本質的に果物であり、同じ方法で処理できることが保証されています。たとえば、プログラマーは、 colorsugar_contentis_ripeなどの同じ属性の存在を期待できます

プロトタイプベースの言語ではオブジェクトが主要なエンティティです。クラスすら存在しません。オブジェクトのプロトタイプは、オブジェクトがリンクされている単なる別のオブジェクトです。すべてのオブジェクトには1つのプロトタイプリンクがあります(そして1つだけです)。プロトタイプとして選択された既存のオブジェクトに基づいて、新しいオブジェクトを作成できます。オブジェクトフルーツが存在し、アップルオレンジの両方がプロトタイプとしてフルーツを持っている場合、 2つの異なるオブジェクトをアップルオレンジと呼ぶことができます。フルーツクラスのアイデアは明示的には存在しませんが、同じプロトタイプを共有するオブジェクトの同値類。プロトタイプの属性とメソッドは、このプロトタイプによって定義された同値類のすべてのオブジェクトに委任されます。オブジェクトが個別に所有する属性とメソッドは、同じ同値類の他のオブジェクトと共有することはできません。たとえば、属性sugar_contentが予期せずappleに存在しない可能性があります。プロトタイプを介して実装できるのは、 単一の継承のみです。

動的ディスパッチ/メッセージパッシング

通常、オブジェクトに関連付けられたテーブルで実行時にメソッドを検索することにより、メソッド呼び出しに応答して実行する手続き型コードを選択するのは、外部コードではなく、オブジェクトの責任です。この機能は、動的ディスパッチと呼ばれます。呼び出しの変動性が、それが呼び出されるオブジェクトの複数のタイプに依存している場合(つまり、少なくとも1つの他のパラメーターオブジェクトがメソッドの選択に関与している場合)、多重ディスパッチについて説明します。

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

カプセル化

カプセル化は、誤用を防ぐために、データが意味的に関連する関数にのみ表示されるデザインパターンです。データカプセル化の成功は、オブジェクト指向で純粋関数型プログラミングの設計原理として データ隠蔽を頻繁に組み込むことにつながります。

クラスが呼び出し元のコードによる内部オブジェクトデータへのアクセスを許可せず、メソッドのみを介したアクセスを許可する場合、これはカプセル化と呼ばれる強力な抽象化または情報隠蔽です。一部の言語(Javaなど)では、クラスがアクセス制限を明示的に適用できます。たとえば、キーワードを使用して内部データを示し、privateキーワードを使用してクラス外のコードで使用するためのメソッドを指定しますpublicメソッドは、パブリック、プライベート、または中間レベルで設計することもprotectedできます(これにより、同じクラスとそのサブクラスからのアクセスが許可されますが、異なるクラスのオブジェクトからのアクセスは許可されません)。他の言語(Pythonなど)では、これは慣例によってのみ強制されます(たとえば、メソッドの名前がアンダースコアprivateで始まる場合があります))。カプセル化は、外部コードがオブジェクトの内部動作に関係するのを防ぎます。これにより、コードのリファクタリングが容易になります。たとえば、クラスの作成者は、外部コードを変更せずに、そのクラスのオブジェクトがデータを内部的に表す方法を変更できます(「public」メソッド呼び出しが同じように機能する場合)。また、プログラマーが特定のデータセットに関連するすべてのコードを同じクラスに配置することを推奨します。これにより、他のプログラマーが簡単に理解できるようにコードが編成されます。カプセル化は、デカップリングを促進する手法です。

構成、継承、および委任

オブジェクトには、インスタンス変数に他のオブジェクトを含めることができます。これはオブジェクトコンポジションとして知られています。たとえば、Employeeクラスのオブジェクトには、「first_name」や「position」などの独自のインスタンス変数に加えて、Addressクラスのオブジェクトが(直接またはポインタを介して)含まれている場合があります。オブジェクト構成は、「has-a」関係を表すために使用されます。すべての従業員はアドレスを持っているため、すべての従業員オブジェクトは、Addressオブジェクトを格納する場所にアクセスできます(オブジェクト内に直接埋め込まれるか、ポインターを介してアドレス指定された別の場所にあります)。 。

クラスをサポートする言語は、ほとんどの場合、継承をサポートしますこれにより、クラスを「is-a-type-of」関係を表す階層に配置できます。たとえば、クラスEmployeeはクラスPersonから継承する場合があります。親クラスで使用できるすべてのデータとメソッドは、同じ名前の子クラスにも表示されます。たとえば、クラスPersonは、メソッド「make_full_name()」を使用して変数「first_name」と「last_name」を定義できます。これらは、変数「position」と「salary」を追加する可能性のあるクラスEmployeeでも使用できます。この手法により、直感的な方法で実際の関係をミラーリングできる可能性があることに加えて、同じ手順とデータ定義を簡単に再利用できます。開発者は、データベーステーブルやプログラミングサブルーチンを利用するのではなく、ユーザーがよく知っているオブジェクトを利用します。アプリケーションドメインのオブジェクト。[21]

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

抽象クラスをオブジェクトにインスタンス化することはできません。それらは、インスタンス化できる他の「具体的な」クラスへの継承の目的でのみ存在します。Javaでは、finalキーワードを使用して、クラスがサブクラス化されないようにすることができます。

継承よりも構成の原則は、継承の代わりに構成を使用する関係を実装することを提唱しています。たとえば、クラスEmployeeは、クラスPersonから継承する代わりに、各Employeeオブジェクトに内部Personオブジェクトを与えることができます。これにより、クラスPersonに多くのパブリック属性またはメソッドがある場合でも、外部コードから非表示にすることができます。Goなどの一部の言語は、継承をまったくサポートしていません。

オープン/クローズド原則」は、クラスと関数は「拡張のためにオープンであるが、変更のためにクローズされるべきである」と主張しています。

委任は、継承の代わりに使用できるもう1つの言語機能です。

ポリモーフィズム

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

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

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

再帰を開く

オープン再帰をサポートする言語では、オブジェクトメソッドは、通常、thisまたはと呼ばれる特別な変数またはキーワードを使用して、同じオブジェクト(それ自体を含む)で他のメソッドを呼び出すことができますselfこの変数はレイトバウンドです; これにより、あるクラスで定義されたメソッドが、そのサブクラスで後で定義される別のメソッドを呼び出すことができます。

OOP言語

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

動的言語でのOOP

近年、オブジェクト指向プログラミングは動的計画法言語で特に人気があります。PythonPowerShellRubyGroovyはOOP原則に基づいて構築された動的言語ですが、PerlPHPはPerl5とPHP4以降、オブジェクト指向機能を追加しており、ColdFusionはバージョン6以降です。

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

ネットワークプロトコルのOOP

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

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

DDMで定義された分散ファイルサービスの初期バージョン。その後、 Distributed Relational Database Architecture(DRDA) の基盤として拡張されました。

デザインパターン

オブジェクト指向設計の課題は、いくつかのアプローチによって対処されます。最も一般的なのは、ガンマらによって成文化されたデザインパターンとして知られています。より広義には、「デザインパターン」という用語は、ソフトウェアデザインで一般的に発生する問題に対する一般的で反復可能なソリューションパターンを指すために使用できます。これらの一般的に発生する問題のいくつかは、オブジェクト指向開発に特有の影響と解決策を持っています。

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

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

4つのデザインパターンのギャング

デザインパターン:再利用可能なオブジェクト指向ソフトウェアの要素は、1994年にエーリヒ・ガンマリチャード・ヘルムラルフ・ジョンソンジョン・ブリシディーズによって出版された影響力のある本で、しばしばユーモラスに「4人のギャング」と呼ばれます。オブジェクト指向プログラミングの機能と落とし穴を探るとともに、23の一般的なプログラミングの問題とそれらを解決するためのパターンについて説明します。2007年4月の時点で、この本は36回目の印刷でした。

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

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

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

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

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

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

しかし、ニクラウスヴィルト(現在はヴィルトの法則として知られている格言を広めた:「ソフトウェアはハードウェアが速くなるよりも速く遅くなっている」)は、彼の論文でOOPについて、「ガラス越しの良いアイデア」、「このパラダイムは、 「実世界での」システムの構造であるため、複雑な動作を伴う複雑なシステムのモデル化に適しています」[26] ( KISSの原則とは対照的)。

Steve Yeggeらは、自然言語には、アクション(メソッド/動詞)の前に物事(オブジェクト/名詞)を厳密に優先するというOOPアプローチが欠けていると指摘しました。[27]この問題により、OOPは手続き型プログラミングよりも複雑なソリューションに苦しむ可能性があります。[28]

OOPと制御フロー

OOPは、ソースコードの再利用性保守性を高めるために開発されました。[29]制御フローの透過的な表現には優先順位がなく、コンパイラーによって処理されることを意図していました。並列ハードウェアとマルチスレッドコーディングの関連性が高まるにつれ、透過的な制御フローの開発がより重要になり、OOPでは実現が困難になります。[30] [31] [32] [33]

責任とデータ駆動型の設計

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

SOLIDおよびGRASPガイドライン

SOLIDは、Michael Feathersによって発明されたニーモニックであり、5つのソフトウェアエンジニアリング設計原則を詳しく説明しています。

GRASP (General Responsibility Assignment Software Patterns)は、 CraigLarmanによって提唱されたもう1つのガイドラインのセットです

批評

OOPパラダイムは、再利用性とモジュール性の規定された目標を達成していないこと[34] [35]や、他の重要なものを犠牲にしてソフトウェアの設計とモデリング(データ/オブジェクト)の1つの側面を強調しすぎていることなど、多くの理由で批判されています。側面(計算/アルゴリズム)。[36] [37]

Luca Cardelliは、OOPコードは手続き型コードよりも「本質的に効率が悪い」、OOPはコンパイルに時間がかかる可能性があり、OOP言語は「クラスの拡張と変更に関して非常に貧弱なモジュール性」を持ち、非常に複雑になる傾向があると主張しています。 。[34]後者の点は、 Erlangの主な発明者であるJoe Armstrongによって繰り返され、彼は次のように述べていると言われています。[35]

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

Potokらによる研究。OOPアプローチと手続き型アプローチの間で生産性に大きな違いは見られませんでした。[38]

Christopher J. Dateは、OOPの合意された厳密な定義がないため、OOPを他のテクノロジー(特にリレーショナル)と批判的に比較することは困難であると述べました。[39]しかし、DateとDarwenは、 RDBMSをサポートするための一種のカスタマイズ可能な型システムとしてOOPを使用するOOPの理論的基盤を提案しました[40]

記事の中で、ローレンス・クルブナーは、他の言語(LISP方言、関数型言語など)と比較して、OOP言語には独自の長所がなく、不必要な複雑さの重い負担を負わせていると主張しました。[41]

アレクサンダーステパノフは、オブジェクト指向をジェネリックプログラミングと比較して不利です[36]

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

Paul Grahamは、大企業でのOOPの人気は、「平凡なプログラマーの大規模な(そして頻繁に変化する)グループ」によるものであると示唆しています。グラハムによれば、OOPによって課せられた規律は、1人のプログラマーが「過度のダメージを与える」ことを防ぎます。[42]

Leo Brodieは、オブジェクトのスタンドアロンの性質と、ソフトウェア開発の 原則[44]に違反してコードを複製する傾向[43]との関係を示唆しています。

Steve Yeggeは、関数型プログラミングとは対照的に、次のように述べています[45]

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

Clojureの作成者であるRichHickeyは、オブジェクトシステムを現実世界の過度に単純化されたモデルとして説明しました。彼は、OOPが時間を適切にモデル化できないことを強調しました。これは、ソフトウェアシステムの同時実行性が高まるにつれて、ますます問題になっています。[37]

Unixプログラマーでオープンソースソフトウェアの提唱者であるEricS。Raymondは、オブジェクト指向プログラミングを「1つの真のソリューション」として提示するという主張に批判的であり、オブジェクト指向プログラミング言語は、透明性を破壊します。[46] Raymondは、これをUnixおよびCプログラミング言語で採用されているアプローチと比較して不利です[46]

UTF-8Goの作成に携わっているプログラマーのRobPikeは、オブジェクト指向プログラミングを「コンピューティングのローマ数字」と呼び[47] 、OOP言語はデータ構造アルゴリズムからに焦点を移すことが多いと述べています[48]さらに、彼は、問題に対する「慣用的な」解決策が、単にルックアップテーブルを使用するのではなく、6つの新しいクラスを作成することであったJava教授のインスタンスを引用しています[49]

正式なセマンティクス

オブジェクトは、オブジェクト指向システムのランタイムエンティティです。それらは、人、場所、銀行口座、データのテーブル、またはプログラムが処理しなければならない任意のアイテムを表す場合があります。

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

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

も参照してください

システム

モデリング言語

参考文献

  1. ^ Kindler、E。; Krivy、I。(2011)。「高度な制御を備えたシステムのオブジェクト指向シミュレーション」。International Journal of General Systems:313–343。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  2. ^ ルイス、ジョン; Loftus、William(2008)。プログラミング設計のJavaソフトウェアソリューションの基礎第6版Pearson Education Inc. ISBN 978-0-321-53205-3、セクション1.6「オブジェクト指向プログラミング」
  3. ^ マッカーシー、J。; ブレイトン、R。; エドワーズ、D。; フォックス、P。; Hodes、L .; ラッカム、D。; Maling、K .; パーク、D。; ラッセル、S。(1960年3月)。「LISPIプログラマーマニュアル」(PDF)マサチューセッツ州ボストン人工知能グループ、MIT計算センターおよび研究所:88f。2010年7月17日にオリジナル(PDF)からアーカイブされました。 ローカルMITパトワでは、[アトミックシンボルの]アソシエーションリストは「プロパティリスト」とも呼ばれ、アトミックシンボルは「オブジェクト」と呼ばれることもあります。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  4. ^ マッカーシー、ジョン; アブラハム、ポールW。; エドワーズ、ダニエルJ。; ハート、swapnil d。; レビン、マイケルI.(1962年)。LISP1.5プログラマーズマニュアルMITプレスp。 105ISBN 978-0-262-13011-0オブジェクト—原子記号の同義語
  5. ^ a b "「オブジェクト指向プログラミング」の意味についてのDr.Alan Kay"。2003 。 2010年2月11日取得
  6. ^ サザーランド、IE(1963年1月30日)。「Sketchpad:マンマシングラフィカル通信システム」テクニカルレポートNo.296、リンカーン研究所、マサチューセッツ工科大学、国防技術情報センター(stinet.dtic.mil)経由2019年7月17日取得
  7. ^ Simula言語の開発、 Kristen Nygaard Ole-Johan Dahl、p.254 Uni-kl.ac.at
  8. ^ ロス、ダグ。「最初のソフトウェアエンジニアリング言語」LCS / AIラボのタイムラインMITコンピューター科学人工知能研究所2010年5月13日取得
  9. ^ a b Holmevik、Jan Rune(1994)。「コンパイルシミュレーション:技術的起源の歴史的研究」(PDF)コンピューティングの歴史のIEEE年報16(4):25–37。土井10.1109 /85.329756S2CID18148999_ 2017年8月30日にオリジナル(PDF)からアーカイブされました2018年3月3日取得  
  10. ^ a b バートランドメイヤー(2009)。タッチオブクラス:オブジェクトとコントラクトをうまくプログラムする方法を学ぶシュプリンガーサイエンス&ビジネスメディア。p。329. Bibcode2009tclp.book ..... M。ISBN 978-3-540-92144-8
  11. ^ ケイ、アラン。「Smalltalkの初期の歴史」2008年7月10日にオリジナルからアーカイブされました2007年9月13日取得
  12. ^ 1995年(6月)Visual FoxPro 3.0、FoxProは、手続き型言語からオブジェクト指向言語に進化しました。Visual FoxPro 3.0は、データベースコンテナ、シームレスなクライアント/サーバー機能、ActiveXテクノロジのサポート、およびOLEオートメーションとnullサポートを導入しています。Foxリリースの概要
  13. ^ FoxProの歴史のウェブサイト: Foxprohistory.org
  14. ^ 1995 Visual FoxPro 3.0レビューアガイド: DFpug.de
  15. ^ Khurana、Rohit(2009年11月1日)。C ++、1Eを使用したオブジェクト指向プログラミングISBN 978-81-259-2532-3
  16. ^ デボラJ.アームストロング。オブジェクト指向開発のクォークOOPの定義の大部分に見られる、継承、オブジェクト、クラス、カプセル化、メソッド、メッセージパッシング、ポリモーフィズム、抽象化の順に、いくつかの基本的な概念を特定した40年近くのコンピューティング文献の調査。
  17. ^ John C. Mitchellプログラミング言語の概念、Cambridge University Press、2003年、 ISBN 0-521-78098-5、p.278。リスト:動的ディスパッチ、抽象化、サブタイプ多態性、および継承。 
  18. ^ Michael Lee Scott、 Programming language pragmatics、Edition 2、Morgan Kaufmann、2006、 ISBN 0-12-633951-1、p。470.カプセル化、継承、および動的ディスパッチを一覧表示します。 
  19. ^ ピアス、ベンジャミン(2002)。タイプとプログラミング言語MITプレス。ISBN 978-0-262-16209-8、セクション18.1「オブジェクト指向プログラミングとは」リスト:動的ディスパッチ、カプセル化またはマルチメソッド(マルチディスパッチ)、サブタイプポリモーフィズム、継承または委任、オープン再帰( "this" / "self")
  20. ^ ブーチ、グレイディ(1986)。Adaによるソフトウェアエンジニアリングアディソンウェスリー。p。220. ISBN 978-0-8053-0608-8おそらく、開発に対するオブジェクト指向アプローチの最大の強みは、実世界のモデルをキャプチャするメカニズムを提供することです。
  21. ^ Jacobsen、Ivar; マグナス・クリスターソン; パトリック・ジョンソン; ガンナーオーバーガード(1992)。オブジェクト指向ソフトウェア工学アディソン-ウェズリーACMプレス。pp。43–69。  _ ISBN 978-0-201-54435-0
  22. ^ 「エメラルドプログラミング言語」2011年2月26日。
  23. ^ ニューアード、テッド(2006年6月26日)。「コンピュータサイエンスのベトナム」相互運用性が発生します。2006年7月4日にオリジナルからアーカイブされました2010年6月2日取得
  24. ^ Meyer、第2版、p。230
  25. ^ M.Trofimov、 OOOP – 3番目の「O」ソリューション:OOPを開きます。ファーストクラス、 OMG、1993、Vol。3、3号、p.14。
  26. ^ Wirth、Nicklaus(2006)。「見るガラスを通しての良いアイデア」(PDF)コンピューター39(1):28–39。土井10.1109 /mc.2006.20S2CID6582369_ 2016年10月12日にオリジナル(PDF)からアーカイブされました2016年10月2日取得  
  27. ^ Yegge、Steve(2006年3月30日)。「名詞の王国での処刑」steve-yegge.blogspot.com 2010年7月3日取得
  28. ^ Boronczyk、ティモシー(2009年6月11日)。「OOPの何が問題になっていますか」zaemis.blogspot.com 2010年7月3日取得
  29. ^ アンブラー、スコット(1998年1月1日)。「オブジェクト指向の再利用の現実的な見方」drdobbs.com 2010年7月4日取得
  30. ^ Shelly、Asaf(2008年8月22日)。「オブジェクト指向モデリングの欠陥」インテルソフトウェアネットワーク2010年7月4日取得
  31. ^ ジェームス、ジャスティン(2007年10月1日)。「マルチスレッドは名詞ではなく動詞です」techrepublic.com。2007年10月10日にオリジナルからアーカイブされました2010年7月4日取得
  32. ^ Shelly、Asaf(2008年8月22日)。「方法:マルチコアプログラミング(マルチプロセッシング)ビジュアルC ++クラス設計ガイドライン、メンバー関数」support.microsoft.com 2010年7月4日取得
  33. ^ ロバートハーパー(2011年4月17日)。「FPを教えることについてのいくつかの考え」存在型ブログ2011年12月5日取得
  34. ^ a b Cardelli、Luca(1996)。「オブジェクト指向言語の悪い工学的性質」ACM計算。Surv28(4es):150–es。土井10.1145 /242224.242415ISSN0360-0300_ S2CID12105785 _ 2010年4月21日取得  
  35. ^ a b アームストロング、ジョー。仕事中のコーダー:プログラミングの技術についての考察ピーター・サイベル編 Codersatwork.com は2010年3月5日にWaybackMachineでアーカイブされ、 2009年11月13日にアクセスされました。
  36. ^ a b ステパノフ、アレクサンダー「STLport:A.Stepanovへのインタビュー」2010年4月21日取得
  37. ^ a b リッチヒッキー、JVM言語サミット2009基調講演、私たちはまだそこにいますか?2009年11月。
  38. ^ ポトク、トーマス; Mladen Vouk; アンディリンドス(1999)。「商業環境で開発されたオブジェクト指向ソフトウェアの生産性分析」(PDF)ソフトウェア–実践と経験29(10):833–847。土井10.1002 /(SICI)1097-024X(199908)29:10 <833 :: AID-SPE258> 3.0.CO; 2-P 2010年4月21日取得
  39. ^ CJ日付、データベースシステムの概要、第6版、650ページ
  40. ^ CJデイト、ヒュー・ダーウェン。Foundation for Future Database Systems:The Third Manifesto(2nd Edition)
  41. ^ Krubner、ローレンス。「オブジェクト指向プログラミングは費用のかかる災害であり、終わらせなければなりません」smashcompany.com。2014年10月14日にオリジナルからアーカイブされました2014年10月14日取得
  42. ^ グラハム、ポール「ARCが特にオブジェクト指向ではない理由」PaulGraham.com 2009年11月13日取得
  43. ^ ブロディ、レオ(1984)。Thinking Forth(PDF)pp。92–93 2018年5月4日取得
  44. ^ ハント、アンドリュー。「自分を繰り返さないでください」カテゴリエクストリームプログラミング2018年5月4日取得
  45. ^ 「Steveyのブログ暴言:名詞の王国での処刑」2020年5月20日取得
  46. ^ a b エリックS.レイモンド(2003)。「Unixプログラミングの芸術:Unixとオブジェクト指向言語」2014年8月6日取得
  47. ^ パイク、ロブ(2004年3月2日)。"[9fans] Re:スレッド:名誉のバッジをカーネルに縫い付ける"comp.os.plan9(メーリングリスト)2016年11月17日取得
  48. ^ パイク、ロブ(2012年6月25日)。「少ないほど指数関数的に多い」2016年10月1日取得
  49. ^ パイク、ロブ(2012年11月14日)。「数年前にこのページを見ました」2018年8月14日にオリジナルからアーカイブされました2016年10月1日取得
  50. ^ ポール、エリック。「カテゴリデータ型のサブタイピングと継承」(PDF)2011年6月5日取得
  51. ^ a b アバディ、マーティン; カーデリ、ルカ(1996)。オブジェクトの理論Springer-Verlag New York、Inc。ISBN 978-0-387-94775-42010年4月21日取得

さらに読む

外部リンク