オブジェクト指向プログラミングは実際に現実世界をモデル化していますか？[閉まっている]

私は、オブジェクト指向プログラミングが現実世界のモデリングに基づいていることをよく見ましたが、それは本当ですか？

私には、ビジネス層以外の何も真実ではないようです。私のGUIクラス/データアクセスクラスは、現実の世界では何もモデリングしていません。私のビジネス層にも、オブザーバー、マネージャー、工場など、現実世界のオブジェクトではないクラスがあります。カプセル化などを利用するようにクラスを設計しようとしていますが、現実の世界はカプセル化されていますか？

私が作成するオブジェクトの中には、現実世界のオブジェクトをモデリングしているものがありますが、OOP前のコードは同じことをしないでしょうか？OOは、Customerのような概念をコードベースに最初に組み込んだ人ではなかったと思います。しかし、オブジェクト指向は本当に物事をモデル化する方法に関するものであり、そのモデル化の方法は私にとって現実の世界に触発されていないようです。

では、オブジェクト指向プログラミングは実際に現実世界をモデル化していますか？

いいえ、まったくありません。

ただし、データ構造に作用するいくつかのメソッドとともに、複雑なデータ構造を保持するための素晴らしい抽象化を作成できる方法論です。

あらゆる種類のモデルは、現実世界を完全にモデル化するのではなく、モデル化しません。

それらは、選択した部分、つまり手元のアプリケーションに関連する部分をモデル化します。

あなたが話しているのは（オブザーバー、マネージャー、工場など）、インフラストラクチャであり、抽象化を正しく行い、永続化などの必要な機能をサポートするのに役立ちます。

とにかく、モデルとは何ですか：
モデルは、実世界のシステムまたはイベントの動作を説明するために使用される簡略化された表現です

オブジェクト指向プログラミングでは、現実の世界をモデル化できますか？

絶対そうです

現実の世界に正確に一致するようにシステムをモデル化することはほとんど不可能です。

現実の世界を正確にモデル化する必要がありますか？

番号

すべてをモデル化できると言ったからといって、すべてをモデル化する必要があるわけではありません。実際、有用なモデリングの本質は、簡略化された表現を提示することです。現在のビジネスニーズを表現するのにどれだけの単純化で十分であり、何を省略する必要があるかは、この手法をうまく使用することと、この手法で迷子になるか、まったく使用しないかの微妙なバランスです。

もちろん、実際には存在しないエンティティもありますが、モデリングによってのみ実際に概念化できます。

名詞とクラスの間に関係があることを教えると、いらいらする悪い習慣が生まれ、それを後でせっかちな建築家や上級エンジニアが押しつぶさなければならないと思います。

教えておくべきことは、クラスが脳のように抽象オブジェクトをモデル化するということです。特定の物理的な車にマッピングされない「車」という抽象的な概念が頭にあり、再利用可能であり、車の特定の実装はそれを継承できます。あなたの脳は、あなたのために概念をメタモデル化しさえします。あなたは思考が何であるか、概念が何であるかの精神モデルを持っています。

頭の中ですでに生成しているモデルを特定するように人々に教えたなら、彼らは実際のソフトウェアを構築するための準備ができているはずです。

... 世界は、オブジェクト指向の構文で表現できるものよりも豊かです。

人々がすべてのシステムを理解し説明するために普遍的に使用するいくつかの一般的な概念、つまりオブジェクトの型に合わない概念を考えてください。「原因/効果」の「前/後」パラダイム、および「システムの状態」の概念は、最も鮮明な例です。実際、「コーヒーの醸造」、「乗り物の組み立て」、または「火星へのローバーの着陸」のプロセスは、単純なオブジェクトに分解することはできません。はい、彼らはオブジェクト指向言語でそのように扱われていますが、それは不自然で直感に反します。OOには順序付け、状態、または原因の概念がないため、ルーチン自体のシーケンス（どの因果関係に基づいてどの条件の下で何が先行するか）には、OOに意味のある表現がありません。

プロセスは、実世界およびプログラミングで非常に一般的です。トランザクション、ワークフロー、オーケストレーション、スレッド、プロトコル、およびその他の本質的に「手続き」の概念を処理するために、長年にわたって精巧なメカニズムが考案されてきました。これらのメカニズムは、OOプログラミングに固有の時間不変の不足を補おうとするため、複雑さを生みます。代わりに、「前/後」、「原因/効果」、そしておそらく「システム状態」などのプロセス固有のコンストラクトを言語のコア部分にすることにより、ルートで問題に対処する必要があります...

引用元：Victoria Livschitz、The Next Move in Programming

はい、オブジェクト指向は実際のエンティティをモデル化するためによく使用できます。

私のビジネス層でさえ、実世界のオブジェクトではないオブザーバー、マネージャー、工場などのクラスを持っています。

オブジェクト指向開発とデザインパターンを混同しないでください。オブジェクト指向の分析と設計は、保守可能なコードのプログラミングにアプローチする手段です。OO言語と相まって、プログラマーは、OOの柱（カプセル化、ポリモーフィズム、継承）を通じて再利用可能なコードを作成することができます。

エンティティをカプセル化するために、そのエンティティを実世界の対応物の後にモデル化できます。たとえば、ギターがある場合、ギタークラスは実際のギターの動作とプロパティをカプセル化します。たとえば、ギターを抽象化して、IInventoryItemポリモーフィズムと継承によるコードの再利用の可能性を活用することができます。

一方、ギターの工場は、さまざまなタイプのギターのメンテナンスに役立つことがあります。これはオブジェクト指向のせいではありません。むしろ、ファクトリーは、そのような目的でメンテナンスコードをうまく作成する実証済みの手段として、時の試練に耐える設計パターンです。言い換えれば、私たちプログラマーはしばしば同様の問題を解決しています。そこで、それらを解決するための共通のソリューションを思いつきました（車輪を再発明しないでください）。

これは、オブジェクト指向が現実の世界をモデル化しなければならないということでも、モデル化するのが常に最適なソリューションであるということでもありません。簡単に言えば、それは経験則として「OOが現実世界をモデル化する」ことは完全に理にかなっています。

それはあなたが話している実世界に依存します。

ホルヘルイスボルヘスは、「Tlön、Uqbar、Orbis Tertius」というストーリーを書きました。そこでは、住民の1人が現実世界をまったく異なって知覚しているようです。

[...]架空のTlönの人々[...]は、世界の現実を否定し、極端な形のベルケリアの理想主義を保持しています。彼らの世界は、「空間内のオブジェクトの同時性としてではなく、独立した行為の異種のシリーズとして」理解されています。Tlönの想像される言語の1つには名詞がありません。その中心単位は、「副詞の力を持つ単音節の接尾辞または接頭辞によって修飾される非個人的な動詞」です。ボルヘスは、「月が水面上に上がった」に相当するTlönicをリストしています。[...]Tlönの別の言語では、「基本単位は動詞ではなく、単音節の形容詞」であり、2つ以上の組み合わせで名詞を形成します。「moon」は「round airy-light on暗い」または「

（本に関するウィキペディアの記事からコピー）

私にとって、この点は、世界が私たちと違って知覚されるということではなく、ちょっと決まり文句ですが、現実の構造自体の認識は、自然言語であろうとプログラミング言語であろうと、話す言語に依存します。TlöneseはLispに非常に満足しており、Java（別名The Kingdom Of Nouns）を非常に不自然だと思うかもしれませんが、ほとんどのテラプログラマーは関数型言語よりもオブジェクト指向を好む傾向があります。私は両方のスタイルが好きです。なぜなら、それは主に視点の問題だと思うからです。いくつかの問題は関数型で最もよく攻撃され、他のいくつかはオブジェクト指向プログラミング技術で攻撃されます。優れたプログラマーは、解決を試みる前に、常にさまざまな角度から難しい問題に目を向けます。または、アラン・ケイが言ったように、視点は80 IQポイントの価値があります。

それで、あなたの質問に対する私の答えは：あなたはどの現実の世界について話しているのですか？そしてどうやって？

私が作成するいくつかのオブジェクトは実世界のオブジェクトをモデリングしていますが、OOP前のコードは同じことをしませんか？

私は言わないと思います。OOPは、物事（プロパティ/オブジェクト）とそれらにできること/できること（メソッド）の間の関係を縛りますが、手続き型プログラミングはこれを行いません（厳密なタイピングを使用する場合は少しですが）。モデルとは、個別の部品やプロセスを定義することだけでなく、それらがどのように適合するかを定義することでもあり、OOPはこれが特に得意です。

私は、オブジェクト指向プログラミングが現実世界のモデリングに基づいていることを繰り返し見ましたが、それは本当ですか？

はい。ここの強調はに基づいています。OOPは現実の世界をモデル化せず（もしそうであれば、偶然）、それは想定されていません。OOPが行うことは、現実の世界をモデル化する方法で、プログラミングの問題をモデル化できるようにすることです：動作の抽象化によって定義されるエンティティのシステムとして。

OOコードは通常、現実の世界をモデル化するものではありません-少なくともそれは目標ではありません。より現実的な方法で、より現実的な方法でコードについて考えることができます。これは引用が言っていることです。

私たちの世界をモデル化するのではなく、私たちの世界の人間の解釈をモデル化します。人間は自然に物を物として分けます。オブジェクト指向は、人間が自分の考え方をプログラムできるようにするため、効果的です。

OOPは現実世界とそこに含まれるオブジェクトの完全なモデルではないかもしれませんが、現実のソフトウェアの複雑さの増大に対処するのに役立つ方法論です。また、論理的に関連するチャンクに分割することにより、コードの記述を改善します。

古いプロシージャ指向の方法でも確かに結果が得られますが、OOPは、大規模で複雑なプロジェクトを扱う場合でも、より迅速かつ比較的簡単にそこに到達するのに役立ちます。

抽象化とカプセル化は、問題の核心に集中するのに役立ちますが、実際に問題を引き起こす配管のすべてを隠します。継承を使用すると、コードのさまざまな側面間の意味のある論理的な関係を確立できます。ポリモーフィズムはコードの再利用を促進し、バリエーション（頻繁に発生する問題の「既存のオブジェクトとほぼ同じ」カテゴリ）を簡単に処理し、オブジェクトに関連付けられたセマンティクスを拡張することでコードを拡張できます。

OOPは、実際のシステムの複雑さのすべてに効果的な方法で対処できる実証済みの支援に似ていると感じています。したがって、それは現実世界の非常に完全なモデルではないかもしれませんが、十分に近く、作業を完了させるのに役立ちます。

私は、オブジェクト指向プログラミングが現実世界のモデリングに基づいていることを繰り返し見ましたが、それは本当ですか？

私には、ビジネス層以外の何も真実ではないようです。

いいえ。ご指摘のとおり、OOP言語で「モデル化された」ものの多くは、メッセージキュー、コントローラー、スタックなどの抽象的な概念です。

あなたのビジネス層でさえ、あなたはまだ「現実世界」をモデリングしていません。従業員クラスがあると仮定します。従業員は人間でもあり、哺乳類でもあり、動物でもあり、また人間でもあります…（あくび）従業員は好きな色をしていて、特定の服を着て特定のものを信じています。要するに、現実の世界には非常に複雑な範囲があり、ほとんどのプログラムでキャプチャしようとさえしていません。

モデリングでは、当面のタスクにとって意味のあるモデルの側面にのみ焦点を当てます。タイムエントリシステムを設計している場合、おそらく何らかのEmployeeクラスが必要ですが、そのクラスには従業員のお気に入りの色を表現するプロパティは必要ありません。

したがって、モデルは「現実の世界」を完全に表現しようとしないでください。

私が作成するいくつかのオブジェクトは実世界のオブジェクトをモデリングしていますが、OOP前のコードは同じことをしませんか？OOは、Customerのような概念をコードベースに最初に組み込んだ人ではなかったと思います。

あなたは正しいです。OOPではない大規模なプログラムを見ると、データ構造を中心に整理されていることがよくあります。データ構造と操作するすべての関数は、明確にするために互いに近くで定義されます。（subversionプロジェクトはこの良い例です。データ構造と関数にはモジュール名が接頭辞として付けられているため、どの構造と関数が相互に使用するのかが明確になります。）

私はプログラミング言語の歴史の専門家ではありませんが、OOPは、コードがこのように編成されたとき、コードがより明確で理解しやすいというカジュアルな観察から生まれたため、言語デザイナーはそのタイプの編成で言語の設計を開始しましたより厳密に実施されます。

OOPと非OOPの最大の違いは、OOPがコードをデータにバインドすることです。そのため、次のようなコードを呼び出すのではなく、

verb(noun);

代わりにこれを行います：

noun->verb();

これは文法的な違いのように見えるかもしれませんが、違いは実際には考え方にあります。オブジェクトに何をすべきかを指示します。通常、オブジェクトの内部状態や動作は何でも構いません。オブジェクトを説明するとき、それを操作するためにはパブリックインターフェイスのみを説明する必要があります。

オブジェクト指向プログラミングは実際に現実世界をモデル化していますか？

完全ではありません。

現実の世界では、実際の問題に直面しています。モデルとなる構築したいシステムを複製するパラダイムを使用して、この問題を解決したいと考えています。

たとえば、ショッピングカートアプリケーションが手元の問題であった場合、次のような異なるエンティティがあります。

1. 書籍、ガジェット、車などの複数のメンバーを含むことができる抽象的な用語である製品は、再び細分化することができます。

2. （売上税）のような税基準は、政府のポリシーに基づいて変更されるため、ソフトウェアが実装される場所に依存します。

3. 税は、製品が税基準とともに輸入されたかどうかに基づいて考慮されます。

4. ユーザーは、製品などのリストを含むショッピングカートを所有できます。

ご覧のように、解決しようとしている実際の問題がありますが、OOPパラダイムにモジュール化して、可能な限り実際のシステムに近づけるようにしています。

あなたは非常に散文的で歴史的な声明を意図していることを読みすぎていると思います。オブジェクト指向プログラミング、クラス、ポリモーピズム、仮想関数などのアイデアの多くは、1960年代（http://en.wikipedia.org/wiki/Simula）のSimula言語で導入されました。名前が示すように、Simulaはシミュレーションを記述するための言語として設計されました。そう、歴史的に、はい、オブジェクト指向のアイデアは「現実の世界」をモデル化するために導入されました。他のスタイルよりも成功するかどうかは、議論の問題です。

私が作成するいくつかのオブジェクトは実世界のオブジェクトをモデリングしていますが、OOP前のコードは同じことをしませんか？

OOPとpre-OOPコードの最大の違いは、前者は、相互に対話する個別のエンティティのグループとして現実世界の状況をモデル化することです。独自のアクションを持つ外部イベント。後者は、それ自体では何もしない大きなデータの塊としてすべてをモデル化しますが、計算は「発生するもの」を表し、それらの一部またはすべてに影響を与える可能性があります。

現実の世界をより良くモデル化するかどうかにかかわらず、それはあなたがモデル化する世界のどの側面に依存します。たとえば、火が周囲のオブジェクトに与える影響を説明する物理シミュレーションは、光と熱の両方が適切であるため、「従来の」アプローチでより適切に表されます。他のオブジェクトの外部状態と内部状態の両方に影響し、特定の各オブジェクトの動作に応じて変化せず、プロパティのみの影響を受ける定義済みプロセス。

一方、相互作用して目的の動作を生成するさまざまなコンポーネントをモデリングしている場合、それらを受動的なものではなくエージェントとして扱うと、何も見落とさずに正しく実行できます。テレビの電源を入れたい場合は、ボタンを押すだけTV.turnOnです。電源コードが抜かれている場合は、確認してくれます。そのため、コグ自体（正しくプログラムされている場合）がプライマリインタラクションの結果として発生するセカンダリインタラクションを処理するため、コグをオンにして、タッチしている他のコグをオンにすることを忘れるリスクはありません。

しかし、オブジェクト指向は本当に物事をモデル化する方法に関するものであり、そのモデル化の方法は私にとって現実の世界に触発されていないようです。

世界が実際にどのようにあるかということよりも、私たちが世界を知覚する方法に関係していると思います。すべては単なる原子の束（またはエネルギー、波など）であると主張することはできますが、それは私たちが直面している問題に対処し、周囲の環境を理解し、将来のイベントを予測するというタスクを処理するのに役立ちません（または過去のものを記述する）。したがって、私たちは世界の「メンタルモデル」を作成し、それらのメンタルモデルは、データ+プロセス1よりもオブジェクト指向とのより良い対応を見つけることがよくあります。

また、ほとんどの人がOOPを「古典的なOOP」の同義語と考えていることにも注目してください。これは、分類と物のサブセットを分類的に作成し、オブジェクトを非常に特定のセットに明確に入れます。これは、再利用可能な新しいタイプを作成するのに非常に便利ですが、モデリングしているエンティティがほとんど自己完結型であり、他のオブジェクトとのやり取りを開始する間、やり取りの対象となることはめったにありません。さらに悪いことに、そのエンティティのインスタンスがほとんどない場合（1つだけである場合）、またはインスタンスの構成、動作、またはその両方が大きく異なる場合。

ただし、「プロトタイプOOP」もあります。この場合、オブジェクトは類似したオブジェクトを選択し、それらが異なる部分を列挙することで記述されます。このエッセイは、思考プロセスの技術的ではない良い説明としてお勧めします（Steve Yeggeの標準であっても、投稿全体が大きすぎるので、関連するセクションを指します：P）。繰り返しますが、これは既知のインスタンスと比較して未知のインスタンスを想像するときのメンタルモデルに適していますが、実際の世界の「動作」には必ずしも関係ありません...多くの点で「似ている」として）

「する」がこの質問の重要な部分だと思います。オブジェクト指向プログラミングは確かに実世界の「オブジェクト」をモデル化できると思いますが、これはプログラミングです。悪用されない方法論はないので、Objectsで愚かなことをすることができるからといって、「OOPは現実の世界をモデル化しない」と言うのは公平ではないと思います。それは、ポインターで愚かなことをすることができるので、ポインターは安全ではないと言うよりも公平ではありません。

この問題に関するウィキペディアの記事は、それをうまくまとめています。

現実世界のモデリングと関係
OOPを使用して、現実世界のオブジェクトとプロセスをデジタル対応物に関連付けることができます。ただし、OOPが実世界の直接的なマッピング（否定的な批判のセクションを参照）を促進すること、または実世界のマッピングが価値ある目標でさえあることに全員が同意するわけではありません。Bertrand Meyerは、オブジェクト指向ソフトウェア構築[21]で、プログラムは世界のモデルではなく、世界のある部分のモデルであると主張しています。「現実は二度取り除かれたいとこです」。

問題は、あなたのプログラムが宇宙シミュレーションでない限り、現実の世界の一部、つまり「モデル」だけに関心があるということです。それがモデルの目的であり、表示する必要がある構造と機能を提供します。

現実の世界には物（オブジェクト）があり、物はアクション（メソッド）を実行できます。物事の側面（プロパティ）を定量化できます。OOPは、還元主義的な方法で使用されると、現実世界のものをモデル化するあらゆる可能性を秘めています。すべての複雑なものには、より小さなまたはより具体的なサブクラスがあり、これらすべてにはメソッドを介した自然な相互作用があります。

OOPは抽象化の方法であるため、現実的なことは、OOPが実際に現実世界のオブジェクトを論理的にモデル化するかどうかです。可能なすべてのことを実行する必要がある場合、実際にはモデリングではありません。

適切なコンテキストでオブジェクト指向について考えるために、抽象化のレベルを1つ上げて、プログラミング全般について話しましょう。

かかわらず、あなたがOOまたは機能的なアプローチを取るかどうか、あなたのプログラムはしていませんそれは、何かをしないのですか？プログラムの全体的なポイントは、特定の刺激セットを与えられた特定の行動を示すことです。彼らはので、プログラムがまったく存在していることが理由のようですやる何かを。ここでのキーワードは行動です。

プログラムが実装しなければならない動作を検討することに加えて、プログラムは一般に特定の品質を示す必要があります。たとえば、心臓モニタープログラムに必要な動作を行うだけでは十分ではありません。通常、ほぼリアルタイムで動作するのに十分なパフォーマンスを発揮する必要もあります。プログラムが示す必要のある他の「品質」は、セキュリティ、柔軟性、モジュール性、拡張性、読みやすさなどです。これらをArchitecture Quality Attributesと呼びます。ですから、私たちのプログラムは、特定の行動（機能）目標を達成し、特定の品質（非機能）を示す必要があると言えます。

これまでのところ、これらのどれもオブジェクト指向について話していません。それでは今やろう。

エンジニアが要件（動作、AQA、制約など）を理解すると、疑問が生じます：有用なプログラムになるために必要な品質を発揮しながら、必要なすべてのことを行うようにコードを編成する方法は？オブジェクト指向プログラミングは、プログラムの機能を、連携するオブジェクトのまとまりのあるモジュールに編成するための戦略です。関数型プログラミングは、プログラムの機能を編成するための別の戦略であり、別の方法で行います。どちらの戦略にも長所と短所があります。

機能的な概念の最近の復活を目の当たりにしてきましたが、それは他の理由の中でも特に、非常に分散された処理に対して非常に説得力のある強さを持っているからです。

しかし、オブジェクト指向に戻ると、「現実世界」を必ずしもモデル化していないことがわかります。プログラムの動作を整理して、プログラムが多くのビジネス目標を達成するために必要な品質を発揮できるようにします。TDD、DDD、BDDなどの手法は、オブジェクトを整理する最適な方法を発見する方法です。Principles、Patterns、Practices、Growing Object-Oriented Software Guided by Tests、Specification by Example、およびDomain-Driven Designなどの書籍では、動作指向設計に焦点を当てたオブジェクト指向の理論と実践を示しています。

「オブザーバー、マネージャー、工場など」について読むとき、プログラムが役立つために必要な特定の品質を示すのに役立つオブジェクト指向パターンを適用しています。あなたのニーズがパターンが解決する問題と一致することを考えると、それらは「働く傾向がある」「証明されたレシピ」です。

オブジェクト指向と機能的パラダイムとの間に偏りが見られることなく、オブジェクト指向が何であるかを理解するのに役立つことを願っています。

OOPはプログラミングの観点からすてきなモデルを作成しますが、実際の世界を反映していません。

ただし、実世界には、ドメイン固有言語（DSL）という用語で知られる、より優れた近似があります。たとえば、Booは、人間が読み取れるコードをほぼ平易な英語で書くことができます（記事のサンプル）。

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

別の例は、ガーキン言語に基づく自動化されたユーザー受け入れテストフレームワークです。

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

ついにあなた次第です。ただし、OOPは、構造化プログラミングやプロシージャ指向プログラミングなどの他の方法論よりも正確な方法です。手続き的タクトはあなたの問題を解決する可能性がありますが、OOPに従うことで生活がより楽になります。