OOPそれは自然ではないので難しいですか？
OOPは当然、人々が世界について考える方法に対応します。しかし、私はこの声明に強く反対します：私たちは（または少なくとも私は）世界を次のように概念化します- 関係私たちが遭遇するものの間ですが、OOPの焦点は個々のクラスとその階層を設計することです。
日常生活では、OOPの無関係なクラスのインスタンスであるはずのオブジェクト間に主に関係とアクションが存在することに注意してください。そのような関係の例は次のとおりです。「私の画面はテーブルの上にあります」; 「私（人間）は椅子に座っています」; 「車が道にある」; 「キーボードで入力しています」; 「コーヒーマシンは水を沸騰させます」、「テキストはターミナルウィンドウに表示されます。」
2価（たとえば、「私はあなたに花をあげた」などの3価）動詞について考えます。動詞は、2つのオブジェクトを操作して何らかの結果/アクションを生成するアクション（関係）です。 focusは動作中で、2つ（または3つ）の[文法]オブジェクトの重要性は同じです。
それとOOPを比較すると、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があります。考え方は、名詞を操作するアクション/動詞から名詞にシフトします。名詞を操作する-「テキストがターミナルウィンドウに表示されている」、または「テキストがターミナルウィンドウに表示されている」など、すべてが受動的または反射的な音声で言われているようなものです。
焦点が名詞に移動するだけでなく、名詞の1つ（文法上の主体と呼びましょう）には、他の（文法上の目的語）よりも「重要度」が高くなります。したがって、1つはterminalWindow.show（someText）またはsomeText.show（terminalWindow）と言うかどうかを決定する必要があります。しかし、なぜshow（terminalWindow、someText）を実際に意味しているのに、運用に影響を与えずにこのような些細な決定で人々に負担をかけるのでしょうか。 [結果は操作上重要ではありません-どちらの場合もテキストはターミナルウィンドウに表示されます-クラス階層の設計では非常に深刻になる可能性があり、「間違った」選択は複雑で複雑になる可能性がありますコードを維持する。]
したがって、OOP（class-based、single-dispatch））を行う主流の方法は、IS UNNATURALであり、 CLOSの一般的な方法は私の考え方に近いものですが、悲しいことに、これは普及したアプローチではありません。
これらの問題を考慮して、現在主流の方法であるOOPが非常に人気となったのはなぜ/なぜ発生したのでしょうか？そして、もしあれば、それを逆転するために何ができるでしょうか？
OOPは一部の問題では不自然です。手続き型です。機能的です。 OOPには2つの問題があり、本当に難しいように思えます。
一部の人々はそれがプログラムする唯一の真の方法であり、他のすべてのパラダイムは間違っているように振る舞います。私見誰もがマルチパラダイム言語を使用し、現在取り組んでいる部分問題に最適なパラダイムを選択する必要があります。コードの一部にはOOスタイルがあります。一部は機能します。一部はストレートな手続き型スタイルになります。経験を積むと、どのパラダイムが何に最適かが明らかになります。
a。 OOは、一般的に、動作する状態に強く関連する動作があり、状態の正確な性質が実装の詳細であるが、その存在を簡単に抽象化できない場合に最適です。例：コレクションクラス。
b。手続き型は、特定のデータに強く結び付けられていない一連の動作がある場合に最適です。たとえば、おそらくプリミティブデータ型で動作します。ここでは、動作とデータを個別のエンティティとして考えるのが最も簡単です。例：数値コード。
c。宣言型で書くのがかなり簡単で、状態の存在が実装の詳細であり、簡単に抽象化できるものがある場合は、機能が最適です。例：Map/Reduceの並列処理。
OOPは一般に、カプセル化されたコードの一部が本当に必要な大規模なプロジェクトでその有用性を示しています。これは初心者のプロジェクトではあまり起こりません。
私見それは個人的な好みと考え方の問題です。私はOOにはあまり問題はありません。
私たち（または少なくとも私）は、遭遇するもの間の関係の観点から世界を概念化しますが、OOP=の焦点は、個々のクラスとその階層を設計することです。
これは一般的な見方かもしれませんが、私見ではこれはまったくそうではありません。 OOという用語の発明者であるAlan Kayは、オブジェクト自体ではなく、オブジェクト間で送信されるmessagesを常に強調しました。そして、少なくとも私に対するメッセージは関係を示しています。
日常生活では、OOPの無関係なクラスのインスタンスであるはずのオブジェクト間に主に関係とアクションが存在することに注意してください。
オブジェクト間に関係がある場合、それらは定義ごとに関連付けられます。 OOでは、2つのクラス間の関連付け/集約/使用法の依存関係で表すことができます。
2価（たとえば、「私はあなたに花をあげた」などの3価）動詞について考えます。動詞は、2つのオブジェクトを操作して何らかの結果/アクションを生成するアクション（関係）です。焦点はアクションにあり、2つ（または3つ）の[文法]オブジェクトは同等に重要です。
しかし、彼らはまだ文脈で明確な役割を持っています：主題、目的、行動など。 -）
それとOOPを比較すると、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があります。考え方は、名詞を操作するアクション/動詞から名詞にシフトします。名詞を操作する-「テキストがターミナルウィンドウに表示されている」、または「テキストがターミナルウィンドウに表示されている」など、すべてが受動的または反射的な音声で言われているようなものです。
私はこれに同意しません。私見英語文「Bill、go to hell」は、プログラムコードでbill.moveTo(hell)ではなくmove(bill, hell)としてより自然に読み取られます。そして前者は、実際には元のアクティブな声により類似しています。
したがって、terminalWindow.show（someText）またはsomeText.show（terminalWindow）のどちらを言うかを決定する必要があります。
繰り返しになりますが、端末にテキストを表示するように要求することや、端末にテキストを表示するよう要求することは同じではありません。私見それはどちらがより自然であるかはかなり明白です。
これらの問題を考慮して、現在主流の方法であるOOPが非常に人気になったのはなぜ/なぜですか。
OO開発者の大部分がOOをあなたとは違うように見ているからでしょうか？
一部のプログラマーは、問題の解決方法ではなく、コンピューターの問題を解決する方法について考えたいため、OODを難しいと感じています。
...しかし、OOP=の焦点は、個々のクラスとその階層を設計することです。
OODはそれについてではありません。 OODは、物事がどのように動作し、相互作用するかを理解することです。
2価（たとえば、「私はあなたに花をあげた」などの3価）動詞について考えます。動詞は、2つのオブジェクトを操作して何らかの結果/アクションを生成するアクション（関係）です。焦点はアクションにあり、2つ（または3つ）の[文法]オブジェクトは同等に重要です。
OODの焦点は常にアクションにあり、アクションはオブジェクトの動作です。オブジェクトはその振る舞いなしには何もありません。 OODの唯一のオブジェクト制約は、すべてが何かによって行われなければならないということです。
私はその行為者が何かをすることよりも重要だとは思っていません。
しかし、なぜshow（terminalWindow、someText）を実際に意味しているのに、運用に影響を与えずにこのような些細な決定で人々に負担をかけるのでしょうか。
私にとってはそれは同じことであり、表記が異なります。あなたはまだ誰が上映者で誰が上映者であるかを決定する必要があります。それがわかったら、OODに決定はありません。ウィンドウはテキストを表示-> Window.Show（text）。
そこにあるもの（特にレガシー領域）の多くは、それがOOでない場合）であると言っています。
コンピュータの問題を解決しているという考え方から抜け出せば、OODは簡単です。あなたは何かをするものの問題を解決しています。
多分、私は要点を得ることができませんが、：
OOP（90年代前半、PascalのBorlandの細いマニュアル）の最初の本を読んでいた）私はその単純さと可能性に単に驚いた（以前は、Cobol、Fortran、アセンブリ言語などを使用していた）先史時代のもの。）
私にとっては、それはかなり明らかです：犬は動物であり、動物は食べる必要があり、私の犬は犬なので、食べる必要があります...
一方、プログラミング自体は本質的に不自然です（つまり、人工的です）。人間の発話は人工的なものです（私を責めないでください。私たちはみんな他の人から私たちの言語を学んでおり、英語を発明した人は誰も知りません）。一部の科学者によると、人間の心は彼が最初に学んだ言語によって形成されます。
私の認めるように、現代のOO言語の一部の構成は少し厄介ですが、それは進化です。
OOP=は世界をモデル化することでした。私がそれを正しく行わないと、何かが来て、お尻に噛みつくかもしれないと思いました。すべてがオブジェクトまたはエンティティであるかのように見せかける問題に非常に気づいていたため、OOPでのプログラミングについては非常に暫定的で自信がありませんでした。
それからSICPを読んで、それが本当にデータ型とそれらへのアクセスの制御についてであるという新しい理解に行きました。 OOPでは、あなたが世界をモデル化しているという誤った前提に基づいているため、私が溶けてしまったすべての問題。
この誤った前提が私に与えた計り知れない困難に、私はまだ驚嘆します（そして、私がどのように自分をそれに見合わせさせたか）。
私たち（または少なくとも私）は、遭遇するもの間の関係の観点から世界を概念化しますが、OOP=の焦点は、個々のクラスとその階層を設計することです。
あなたは（IMO）誤った前提から始めています。オブジェクト間の関係は、オブジェクト自体よりも間違いなく重要です。それはオブジェクト指向のプログラム構造を与える関係です。オブジェクトのクラスがそのオブジェクトcanの動作を決定するため、継承、つまりクラス間の関係はもちろん重要です。しかし、クラスによって定義された境界内でオブジェクト実際に行うを決定するのは、個々のオブジェクト間の関係であり、したがってプログラムの動作です。
オブジェクト指向のパラダイムは、オブジェクトの新しいカテゴリを考えるのが難しいためではなく、オブジェクトのグラフを想像してそれらの間の関係を理解することが難しいため、最初は難しい場合があります。特に、それらの関係を説明する方法。これが、デザインパターンが非常に役立つ理由です。デザインパターンは、ほぼ完全にオブジェクト間の関係についてです。パターンは、より高いレベルでオブジェクトの関係を設計するために使用できるビルディングブロックと、それらの関係を説明するために使用できる言語の両方を提供します。
物理的な世界で働くクリエイティブな分野でも同じことが言えます。だれでもたくさんの部屋をまとめて、建物と呼ぶことができます。部屋には最新の設備がすべて整っているかもしれませんが、それだけでは建物は機能しません。建築家の仕事は、部屋と建物の環境を使用する人々の要件に関して、部屋間の関係を最適化することです。これらの関係を正しくすることが、機能的および美的観点の両方から建物を機能させるものです。
OOPに慣れるのに問題がある場合は、オブジェクトがどのように組み合わされているか、およびオブジェクトの責任がどのように調整されているかについて、もっと考えることをお勧めします。まだ読んでいない場合は、デザインパターンについて読んでください。読んだパターンはすでに見たことがあると思いますが、名前を付けると、木だけでなく、スタンド、雑木林、雑木林、森、林、木地、そして最終的には森。
はい、OOP自体は非常に不自然です-現実の世界は完全に階層的な分類法で構成されているわけではありません。その一部はそのようなものでできており、その部分は適切にできる唯一のものですOOで表現されます。残りはすべて、このような些細で制限された考え方に自然に適合することはできません。自然科学を参照してください。最も単純な、または少なくとも理解可能な形式で表現するために、多くの異なる数学言語が発明されました。現実世界の複雑さの方法であり、オブジェクトやメッセージの言語に簡単に変換できるものはほとんどありません。
[〜＃〜]編集済み[〜＃〜]
まず第一に、OOP=難しい、または他のプログラミングパラダイムよりも難しいことは見つかりませんでした。プログラミングは本質的に難しいです。現実世界からの問題を解決しようとするので、現実世界は一方で、この質問を読んだとき、他のパラダイムよりもOOP「より自然」ですか？それで、より効果的ですか？
命令型プログラミング（IP）とオブジェクト指向プログラミング（OOP）の比較研究に関する記事を見つけたことがあります（参照できるようにもう一度見つけたいと思います）。彼らは基本的に、IPとOOPを使用するプロのプログラマーの生産性をさまざまなプロジェクトで測定しており、大きな違いは見られなかったという結果になりました。そのため、大きな違いはないと主張しました。 2つのグループ間の生産性、そして実際に重要なのは経験です。
一方、オブジェクト指向の支持者は、システムの開発の初期段階ではOOP=が必須よりも時間がかかる可能性がありますが、長期的にはコードの保守が容易であり、データと操作が緊密に統合されているため、拡張されます。
私は主にOOP言語（C++、Java））で作業しましたが、大規模なプロジェクトで一度も試したことがないのに、PascalまたはAdaを使用して生産性を高めることができると感じることがよくあります。
それとOOPを比較すると、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があります。
[カット]
したがって、OOP（class-based、single-dispatch））を行う主流の方法は、IS UNNATURALであり、 CLOSの一般的な方法は私の考え方に近いものですが、悲しいことに、これは普及したアプローチではありません。
この最後の段落をより注意深く読んだとき、私はようやくあなたの質問の要点を理解し、私の答えを一から書き直さなければなりませんでした。 :-)
他のOO複数のオブジェクトが1つだけではなくメッセージを受信する提案を知っています。つまり、複数のオブジェクトがメッセージを受信するときに対称的な役割を果たします。はい、これはより一般的で、おそらくより自然に見えます（制限が少ない）OOP私にアプローチします。
一方、「マルチディスパッチ」は「シングルディスパッチ」を使用して簡単にシミュレートでき、「シングルディスパッチ」は実装が簡単です。多分これが「マルチディスパッチ」が主流にならない理由のひとつでしょう。
OOPは難しくありません。うまく使用するのが難しいのは、プログラマがランダムな格言を聞き、神の4つのギャングの祝福、祝福されたマーティンファウラー、または祝福を受けるマーティンファウラー、または彼らが読んでいる他の誰でも。
これは、OOPの問題の一部にすぎません。
基本的に、機能は二流市民になり、これは悪いことです。
現代の言語（Ruby/python）はこの問題に悩まされることなく、ファーストクラスのオブジェクトとして機能を提供するだけでなく、クラス階層を構築することなくプログラムを作成できます。
排他的なOOPパラダイムを探すのをやめて、JavaScriptを試してみてください。
私は現在、UIオブジェクトがイベントドリブンインターフェイスの下で動作しているスキームの何かを解決しました。つまり、起動すると内部的に定義されたアクションが発生する典型的なパブリックメソッドのようになります。しかし、それが発生すると、実際に起こるのは、オブジェクト自体でイベントをトリガーし、そのオブジェクト内の事前定義されたハンドラーが応答することです。このイベントと、プロパティをアタッチできるイベントオブジェクトは、他のリスナーに渡され、リスニングを気にするすべての人が聞くことができます。オブジェクトを直接リッスンすることも、一般的にそのイベントタイプをリッスンすることもできます（イベントは、ファクトリによって構築されたすべてのオブジェクトがリッスンできる汎用オブジェクトでもトリガーされます）。したがって、たとえば、ドロップダウンリストから新しい項目を選択するコンボボックスがあります。 comboBoxは、独自の表示値を設定し、必要に応じてサーバーを更新する方法を知っていますが、現在の値に関連付けられている選択リストを交換するために、他のコンボボックスをリッスンすることもできます。最初のコンボボックス。
必要に応じて（そして、私が通常は望んでいないことに気付いて驚いた-イベントがどこから来ているのかがわからないときの読みやすさの問題です）、渡されたイベントオブジェクトを介して完全なオブジェクト分離とコンテキストを確立できます。いずれにせよ、複数のレスポンダを登録できるため、シングルディスパッチを回避できます。
しかし、私はこれをOOPだけで行うのではなく、JSは '適切に'さえありませんOOPいくつかの定義によって、私は陽気だと思います。適切な私の意見では、より高いレベルのアプリ開発は、パラダイムを状況に応じて機能するものに曲げる力を持っているため、必要に応じてクラスをうまくエミュレートできます。しかし、この場合は、関数（パスハンドラー）の側面を混合しています周り）OOPで。
さらに重要なことに、私が持っているものはかなり強力だと感じています。あるオブジェクトが別のオブジェクトに作用しているとは考えていません。私は基本的に、オブジェクトが何を気にするかを決定し、オブジェクトを整理するために必要なツールを提供し、ミキサーにドロップして、それらを相互に反応させます。
だから私が言っているのはこれだと思います：これはswitch文のような問題ではありません。それは混ぜ合わせです。問題は、言語と流行であり、それがユーバー・アレスの1つだと信じてもらいたいのです。ジュニアJava開発者は、OOPがデフォルトで常に適切に実行していると思っているときに、どうすればよいですか？
人々がOOPを使用して現実を表現しようとすると、いくつかの困難が生じると思います。誰もが知っている車には4つの車輪とエンジンがあること誰もが知っている自動車はStart()、Move()およびSoundHorn()を使用できることを知っています。
私はいつもこれをやろうとするのをやめるべきだと気づいたときに私の頭の中で光がクリックされました。オブジェクトは、名前を共有するものではありません。オブジェクトは、問題の範囲に関連するデータの十分に詳細なパーティションです（つまり、ある必要があります）。問題の解決に必要なものを正確に持っていることはought、これ以上でもそれ以下でもありません。オブジェクトをある振る舞いに関与させると、同じ振る舞いが曖昧なサードパーティの仕事である場合よりも多くのコード行が生成される場合（「ポルターガイスト」と呼ばれる場合もあります）、ポルターガイストはチップを獲得します。
トースターと車で説明された。どちらにもスプリングがあるため、「スプリング」オブジェクトがあり、サイズ、強度などは異なりますが、どちらも「スプリング」であり、その比喩を車に拡張すると、ホイールがたくさんあります。 （ホイール、明らかに、そしてステアリングホイールなど）そしてそれは非常に理にかなっています。
プログラムはオブジェクトのリストと考えることができ、視覚化するのははるかに簡単です。「それは何かを実行するもののリストであるため、以前に見た命令のリストとは異なります」
OOPの本当の問題は、それが人々に説明される方法です。多くの場合（私のuniクラスで）、私はそれが「ほとんど何もしないクラスの多くについてであり、それらからオブジェクトを作成することができます。これらの概念を説明するために本質的に抽象的な用語を使用しているので、それは多くの人々を混乱させます。レゴで遊んで5歳のときに人々が把握していた具体的なアイデアではなく、.
これは、分類を通じて世界を考える自然な方法です。 OOの概要です。OOPはプログラミングが難しいため難しいです。
いいえ。プログラミングを使用して問題を解決する方法はいくつかあります：関数型、手続き型、論理型、O.O.P。、その他。
現実の世界では、関数型のパラダイムを使用することもあれば、手続き型のパラダイムを使用することもあります。そして時々私達は取り違えました。そして最終的には、それらをプログラミングの特定のスタイルまたはパラダイムとして表現します。
LISPで使用される「すべてがリストまたはアイテムである」というパラダイムもあります。 関数型プログラミングとは異なるものとして言及したい。 PHPはそれを連想配列で使用します。
O.O.P.そして、「すべてがリストまたはアイテムである」というパラダイムは、いくつかの人工知能クラスで覚えているように、MORE NATURALプログラミングスタイルの2つと見なされます。
「O.O.P.は自然ではない」、あなたがO.O.P.について学んだ方法や教えられた方法かもしれません。間違っていますが、O.O.Pではありません。自体。
OOPおよびOOP言語にも問題があると思います。
正しく理解していれば、OOPは、プッシュできるプッシュボタン（メソッド）を持つブラックボックス（オブジェクト）に関するものです。クラスは、これらのブラックボックスを整理するのに役立つものです。
1つの問題は、プログラマーが誤ったオブジェクトにプッシュボタンを配置する場合です。端末はテキストを表示できず、テキストは端末に表示できません。これを実行できるオペレーティングシステムのウィンドウマネージャーコンポーネント。ターミナルウィンドウとテキストは単なるパッシブエンティティです。しかし、このように考えると、ほとんどのエンティティは受動的なものであり、実際に何かを行うオブジェクトは非常に少数しかありません（または単に1つ：コンピュータ）。実際、Cを使用してモジュールに編成すると、これらのモジュールはその少数のオブジェクトを表します。
別の点は、コンピュータが命令を順次実行するだけであるということです。VCRとTelevisionオブジェクトがあるとしましょう。どのようにビデオを再生しますか？あなたはおそらく次のようなものを書くでしょう：
connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();
これは簡単ですが、少なくとも3つのプロセッサ（またはプロセス）が必要です。1つはあなたの役割を果たす、2つ目はビデオデッキ、3番目はテレビです。しかし、通常、コアは1つだけです（少なくとも、すべてのオブジェクトに対して十分ではありません）。大学では、クラスメートの多くは、プッシュボタンが高価な操作をするとGUIがフリーズする理由を理解していませんでした。
したがって、オブジェクト指向の設計は世界をかなりよく表現していると思いますが、それはコンピューターにとって最良の抽象化ではありません。
複雑さを管理するために、機能をモジュールにグループ化する必要がありますが、これは一般に難しい問題です。 OOPは、私たちが試みた他のすべてを除いて、ソフトウェアをそこに整理するための最悪のシステムです。
名詞の内部で相互作用をグループ化する理由は、2つの名詞のどちらをグループ化するかについて曖昧な場合が多いにもかかわらず、名詞の数がたまたま管理可能なサイズのクラスになるためですが、動詞によるグループ化はone-offsのような非常に小さなグループ、またはshowのような関数の非常に大きなグループ。継承などの再利用の概念も、名詞でグループ化するとはるかに簡単に機能します。
また、ウィンドウとテキストのどちらにshowを置くかを決定する問題は、ほとんどの場合、理論よりも実際にははるかに明確です。たとえば、ほぼすべてのGUIツールキットは、コンテナではaddをグループ化しますが、ウィジェットではshowをグループ化します。コードを別の方法で記述しようとすると、2つの方法は交換可能であると抽象的に考えても、その理由はすぐに明らかになります。
これらの問題を考慮して、現在主流の方法であるOOPが非常に人気となったのはなぜ/なぜ発生したのでしょうか？そして、もしあれば、それを逆転するために何ができるでしょうか？
OOPは、以前の一般的な手続き型言語よりも高い抽象度でプログラムを整理するツールを提供するため、人気が高まりました。また、メソッド内に手続き構造を持ち、それらを囲むオブジェクト指向構造を持つ言語を作成することも比較的簡単でした。これにより、手続き型のプログラミング方法をすでに知っているプログラマーが一度に1つずつOO原則を取り上げます。これにより、クラス内にラップされた手続き型プログラムである、名前のみのOOのみのプログラムが多数発生しました。または2つ。
OOを廃止するために、ほとんどのプログラマーが今日知っているもの（ほとんどがOOのある手続き型）から好みのパラダイムに簡単に段階的に移行できる言語を構築します。一般的なタスクを実行するための便利なAPIが提供されていることを確認し、適切に宣伝します。人々は間もなくあなたの言語でX-in-name-onlyプログラムを作るでしょう。そうすれば、人々が実際にXを上手に使えるようになるには何年もかかることが予想できます。
MVCパターンの発明者によって発明された [〜＃〜] dci [〜＃〜] （データ、コンテキスト、および相互作用）を見てください。
DCIの目標は（Wikipediaから引用）です。
- オブジェクト（名詞）の上にシステム動作ファーストクラスのステータスを与えます。
- 急速に変化するシステム動作（システムの動作）のコードと、ゆっくりと変化するドメイン知識（システムの内容）のコードを明確に分離するために、両方を1つのクラスインターフェイスで組み合わせるのではなく。
- クラスの考え方ではなく、人々のメンタルモデルに近いオブジェクトの考え方をサポートする。
ここに 作者による良い記事 があり、コードを表示したい場合は 小さなサンプル実装（.NET） があります。見た目よりもずっとシンプルで、とても自然な感じです。
OOPは当然のことながら、人々が世界について考える方法に対応します。しかし、私はこの声明に強く反対します（...）
本や他の場所で数十年間伝道されているので、私もそれに同意しません。それでも、NygaardとDahlはそのように表現した人物だと思います。彼らは当時の代替案と比較してシミュレーションの設計を考えることがいかに簡単であるかに焦点を合わせていたと思います。
（...）しかしOOPの焦点は、個々のクラスとその階層を設計することです。
この主張は、OOPの誤解がどれほど一般的であるか、およびOOが定義に対してどれほど敏感であるかを考えると、賢明な領域に入ります。私はこの分野で10年以上、業界の仕事とprog。言語に関する学術的な研究の両方であり、「主流OO」の学習を何年も費やしていたことがわかります。それは、以前のクリエイターが目指していたものとの違い（劣っている）に気付いたからです。対象の最新の扱いについては、Wクックの最近の取り組みを参照します。
「「オブジェクト」と「オブジェクト指向」の簡略化された現代的な定義の提案 http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html
これらの問題を考慮して、現在主流の方法であるOOPが非常に人気になったのはなぜ/なぜですか。
たぶん同じ理由QWERTYキーボードが人気になったのか、それともDOSオペレーティングシステムが人気になったのと同じ理由です。物事は、人気のある車に乗るだけで、その特性にもかかわらず、人気を博します。似ているがより悪いバージョンのものが実際のものと見なされます。
そして、それを倒すために何ができるでしょうか？
優れたアプローチを使用してプログラムを作成します。 OOアプローチを使用して同じプログラムを記述します。重要なすべての側面で前者が後者よりも優れた特性を持っていることを示します（システム自体の特性とエンジニアリング特性の両方）。プログラムが選択されたことを示します他の種類のプログラムに適用された場合、提案されたアプローチは関連性があり、提案されたアプローチが高品質の特性を維持します。
最後に、調査結果を私たちと共有してください。