オブジェクト指向プログラミングが主要なプログラミングパラダイムになる歴史的条件は何でしたか？

オブジェクト指向プログラミング言語が影響力を持つようになった経済的（およびその他の歴史的）要因は何でしたか？Simulaが物事を始めたのは知っていますが、ビジネスのニーズが増え続けるためにOOP言語が採用されたのですか？それとも、OOP言語でできる新しいことのせいで採用されたのでしょうか？

編集 私は、言語自体の外で、それらが定着することを可能にするいくつかの要因があったかどうかに本当に興味があります。

短い答え

OO日前のソフトウェアプロジェクトの混乱であったと思います。オブジェクト指向は、根本的に重要な概念を追加することで支援しました- 現実の世界をモデル化します。

最初のオブジェクト指向プログラミング言語は1967年のSimula方式でした。しかし、当時のソフトウェア開発全般はまだラボで行われており、ほとんどのパラダイムはまだハードウェアのケースに近いものでした。

エンタープライズアプリケーション向けのソフトウェアの開発は、さらに10年以上にわたって、他の商用アプリケーションが成長し、1970年代全体でソフトウェア開発が一般的になりました。それらの時代（1980年以前）でも今日も生き残っている言語は、C、Cobol、Fortran、その他の類似言語でした。これらの言語のほとんどは手続き型です。Lispもその日から存在していました-しかし、それが商業開発のための顕著な汎用言語であったかどうかはわかりません。有名な用語「ウォーターフォールモデル」も1970年代初期に造られました。

ほとんどの商用環境では、ソフトウェア開発で最も重要な要素はプロジェクト管理でした。プロジェクトが確実にフィニッシュラインに到達することを保証するために、タイトで少なくとも予測可能な予算と管理要件を凍結することが急務でした。この期間は、1975年の神話的マンマンの 1つでもありました。

70年代の終わりまでには、手続き型言語がそれらの約束を守らなかったため、人々は燃え尽きていたと思います。そして、その当時から存在していたオブジェクト指向の新しいパラダイムが大きくなりました。人々は意見を異にするかもしれませんが、1983年に親しみと実証済みの経験とC、およびオブジェクト指向の約束（元々はクラス付きCという名前でした）に役立つC ++は、オブジェクト指向プログラミングの成功の礎石だったと思います。

より多くの視点のためのいくつかのリファレンス-http://journal.thedacs.com/issue/43/88

では、なぜオブジェクト指向なのでしょうか？

当時（プロジェクトの成功の観点を見ると）-よりよく理解できるものが管理しやすくなるのは理にかなっていると思います。「..人生のすべてがオブジェクトである」という約束のあるオブジェクト指向の方法論は、それが有意義であることが証明される前でさえ、常識のようでした。この要素の実際的な成功は、銃をジャンプする前に手元の現実世界と問題を十分にモデル化するという概念でした。そして、このパラダイムにより、手続き型言語以上のコードを作成する前に多少考えなければならなかったことを考えると、採用したソフトウェアプロジェクトで目に見える成功を示し、それ以来彼らは成功しました！

編集
私はまた、プログラミング言語がそのような基本概念（OOパラダイム、アスペクト、仮想マシン）と並行して同時に進化したことを追加します。新しいコンセプトと新鮮な思考は、新しいプログラミング言語がマスターしたときに初めて現れました。芯！同時に-これらの新しい概念と新しい言語は、新しいビジネス上の問題のためにのみ出現しました。1980年代-大規模ソフトウェアのオブジェクト指向、1990年代のインターネット時代のJava、PHP / ASPなどのWeb向け。プログラミング言語の革新も、主に市場の不連続なニーズによって推進されました。

要約すると、80年代前半は大規模な商用ソフトウェアが離陸した時代でした。手続き型言語を使用したプロジェクトには問題がありましたが、OOは優れた光を示し、プロジェクトをより成功させました。

最大の理由は、XやWindowsなどのグラフィカルユーザーインターフェイスの成功だと思います。GUIは、それ自体で動作を行う複数のオブジェクトで構成されます。オブジェクトは、OOが密接に表すことができます。

一方、テキストベースのユーザーインターフェイス（GUIに似ていない）は、多くの場合、コマンド応答パターンに従うだけで、手続き型言語で簡単に実装できます。ビジネスルールと同様のものは、何十年も手続き言語で実装されており、あまり多くの問題はありません。今日でも、ビジネスアプリケーション用の多くのオブジェクト指向プログラムはかなり手続き的です。データを保持する愚かなオブジェクトと、ビジネスルールを含むステートレスオブジェクト。前者は手続き言語の記録であり、後者は手順です。

私は、OOPを手続き型コードからの自然な進化段階と考えています。

1. 手続きコード：マシンにAを行うように指示し、次にBを行うように指示します。
2. OOP：インターフェース/入力/出力を定義することにより、手順命令を非常に再利用可能なチャンクにパッケージ化します。（警告：簡素化。）

広い視野を持った誰かが鳴り響くと確信していますが、これは単にプログラマーがコードをより速く生成できるようにする、つまりコードの再利用を可能にするという自然な進歩のようです。

この観点では、最大の外的要因は、プロセッサの処理能力のコストの削減でした（典型的なプログラムを作成するための開発者の人件費に対して）。（CPUの費用対プログラマの費用のこの同じトレードオフは、プログラミングの他の多くの側面に影響を与えました。）

最初は命令型プログラミングがありました（それを呼び出すことができれば）。メインフレームに何をどのように計算すべきかを伝える簡単な指示。これらのプログラミング言語は、無条件のジャンプやその他の「構造化されていない」命令を使用し、それらのほとんどは今日の標準では珍しいものです。

それから誰かがプログラミングの構造を思いつきました。for、while、do while、foreachは、今日知っています。比較的複雑なフローを持つアプリケーションを簡単に記述して理解できるようになったため、これは大きな革新でした。このようにして、構造化プログラミングが生まれました。

その後、あちこちで多くのコードを繰り返す必要があり、それを維持するのは悪夢であるため、コードを再利用する方法を考案する必要があると言う他の人々がやってきました。人々は、再利用可能なコードを区切るための手続きと関数を思いついた。これにより、カプセル化と単一責任の原則も生まれました。

その後、一部の学者は、機能は作業中のデータと密接に結び付けられるべきだと述べました。次に、実際の分類が機能する論理的な方法に合わせて、コードの再利用とポリモーフィズムの継承の概念を追加しました。このようにして、第三世代のプログラミング言語とOOPが生まれました。