OOPが登場する前、システムはプログラミングの他のパラダイムでどのようにモデル化されていましたか。
明らかに、ソフトウェアプログラムは1970年代以前に存在し、人々と対話し、重要な場所で使用されていました。
初期のプログラミングパラダイムは、データのモデリングの問題にどのように取り組みましたか。
OOPの前にオブジェクトがなかったと考えるのはばかげたことでしょう。
OOPはクラスの概念を形式化します。これにより、間違いなく優れたコード編成が可能になります。ただし、これらの同じ構成体はアセンブリまたはCで実行できます。さらに、switchステートメントを含むタグ付き構造体は、クラス、サブクラス、およびオーバーライドと同等の機能を提供しますが、形式はかなり低くなります。
68kベースのMacintoshコンピュータは、多くのアセンブリを使用していました(一部はコンパイラが40年前ほど良くなかったためです)。
フィールドをオブジェクトにグループ化する方法は常にありました。
FORTRAN '66 —特に構造またはレコードの正式な構造が欠けている—プログラマーは、個別の配列が対象となるさまざまなフィールドを保持し、各個別の配列内の同じインデックス位置がオブジェクトを構成する並列配列を単に使用します。
フィールドをオブジェクトに構成したり、あるオブジェクトを別のオブジェクトに関連付けたり、あるオブジェクトを別のオブジェクトに置き換えたり、あるオブジェクトを別のオブジェクトとは異なる方法で処理したりする方法は常に(そして常に)あります。
OOPは実際にはmoreモデリングに関する限り制限されています。その理由は、すべての動詞mustが1つの名詞と密接に結びついているためです。他のパラダイムにはその制限はありません。 item.addToCart(cart)
やcart.addItem(item)
を実行するかどうかなど、無茶な決定をする必要はありません。 addItemToCart(item, cart)
を使用できます。
OOPの前は、プロセスとデータを分離するために 構造化プログラミング パラダイムが使用されていました。
この分離はモデリングにも適用されました。
ERD、および程度は低いもののIDEF0が現在も使用されていることに注意してください。
OOは終わりではなく、複雑なシステムを構築するための唯一の手段であることに注意してください。オペレーティングシステムのコードのサイズを見ると、その複雑さに驚かれることでしょう。まだOOがそこにあります。