オブジェクト指向プログラミングパラダイムは、アンチモジュラーであり、アンチパラレルであるため、更新されていますか？
私は論争の的になっている記事を読んだことがあります Teaching FP to freshmen CMUの教授であるRobert Harperによって投稿されました。CMUはもはやオブジェクト指向プログラミングを入門コースは「現代のCSカリキュラムには不向き」です。
そして彼はそれを主張した：
オブジェクト指向プログラミングは、本質的にアンチモジュールであり、アンチパラレルであるので、導入カリキュラムから完全に排除されています。
OOP=を反モジュラーかつ反平行と見なすのはなぜですか？
入門CSカリキュラムクラスを教えるためのハーパーのニーズは実生活プロジェクトのニーズと非常に異なっています。彼の仕事は、新入生に基本的な概念（モジュール性、並列性、帰納法など）を教えることです。そのため、選択された言語（およびパラダイム）がこれらの概念をできるだけ少ない式（構文および概念）で表現できることが非常に重要です。親しみやすさ、ツールサポート、利用可能なライブラリ、実行パフォーマンスなどは、このコンテキストではまったく関係ありません。したがって、次のことを検討するときは、このことに留意してください...
OO is anti-modularであるとの見方は、適切に設計されたクラスのオブジェクトが最終的になりがちである傾向があるとしても、他のクラスへの多数の依存関係の結果です。問題-OO-の依存者の目から見ても、過去数年間のDependency Injection Frameworksの増殖、記事、本、ブログの投稿を見ると明らかになります。 （モックとスタブの出現も興味深い）。
他のヒントはデザインパターンの重要性とそれらを実装することの複雑さです-他のいくつかのプログラミングパラダイムと比較して-例えばファクトリー、ビルダー、アダプター、ブリッジ、デコレーター、ファサード、コマンド、イテレーター、メディエーター、オブザーバー、ストラテジー、テンプレートメソッド、そしてコンポジットはすべて、何らかの方法でOOコードのモジュール性の向上に関連しています。
継承にも問題があります（例：壊れやすい基本クラスの問題）および（サブタイプ）ポリモーフィズムは、複数のクラス間のアルゴリズムの実装をこぼし、継承チェーン全体に変更が波及する可能性があります（アップおよびダウン！）.
反平行であるという料金は、計算と比較して状態の強調に関連しています（別名可変性vs不変性）。前者は、通常、状態が管理されている場所（別名：ファイル）から推測できないため、 subcomputations の依存関係を表現することをより複雑にします（これは、ハーパーの並列処理に関するものです）。 、インスタンス変数が宣言されている場合）どの外部アクターがどの時点でインスタンス変数を変更するか。
状態管理がなく、サブ計算の依存関係を表現したい場所で結合される関数/計算だけなので、不変性と計算に重点を置くことで、サブ計算の依存関係をはるかに簡単に表現できます。
これはおそらく大胆な主張ですが、おそらく Robert Harper が実際のソフトウェアを彼の人生で実際に書いたことはないと思います。彼が気にかけているのはMLと静的型システムだけです。おそらく大きな貢献かもしれませんが、OOPに関する彼の主張がどのように関連しているかはわかりません。
この記事は物議を醸すものではありません。論争は、検討、議論および議論を含みます。あなたがここに持っているのは、議論を提供することに煩わされることなく、2つの非常に基本的な非難を1つの単一の声明で発表する無知な学者です。
OOPが反モジュラーであるという主張は、まったくナンセンスです。私はそれに応答する方法すら知りません、引数が提供されなかっただけでなく、OOP設計によりisを介して個々のモジュール間の結合が非常に低いモジュール性を確立するアプローチカプセル化と抽象化の手段。
OOPが反平行であると主張することは、理解の欠如を示すだけです。 OOPは、同時実行性に関する決定を固定しません。 OOPはそれらを非表示にすることのみを指示します。適切に構築されている場合、オブジェクトの実装が並列であるかどうかはわかりません。
したがって、最終的にはOOPと並列プログラミングは直交します。アクターモデルは、オブジェクトシステムに直接反映できる（ただし、そうである必要はありません）同時実行性のエレガントなモデルであり、両方の手ごわい組み合わせを生み出します。
OOPの問題は、実際にそれを理解している人がほとんどいないということです Alan Kay がそれを定義しました。
- OOPはアプローチです。一部の言語ではパターンを使用して実装されていますが、他の言語では組み込み言語のイディオムを直接使用できます（Ruby、Objective-C、Smalltalk、 Io など）。
- 一般的な考えに反して、OOPはクラスに関するものではありません。それはオブジェクトに関するものであり、オブジェクトは メッセージパッシング 、または同様に漏れのないカプセル化と抽象化の方法に関するものです。
これがJavaがOOPを指す理由です。これは、他の多くのいわゆる「OOP言語」にも当てはまりますが、Javaについては、大学ではJavaを使用する必要があると考えられているようです。 OOPを教えるために。
OOP with Javaの紹介をCSカリキュラムから削除する必要があると考えるすべての人に同意します。また、OOPの基本的な理解が明らかに不足している人は、それを教えるべきではないと思います。そのため、ボブがコースでMLを使用し、しっかりと理解していることを教えるだけの方が良いでしょう。
今のところOOPは、人々がすべてのものに固執することを好む、よりファッショナブルなエチケットです。これはOOPに害を及ぼし、人々を傷つけました。 OOPは古くない。 OOPの黄金時代はまだ到来しておらず、人々はそれが何であるかについて最終的に理解しますnotについて（例えば、キーワードclassを500回使用してすべての可能な問題を解決します）。
あなたはあらゆるストライプの熱狂者を獲得します。
オブジェクト指向プログラミングは特効薬ではありません。それは決してありませんでした。それが何であるかは、誇大広告の犠牲者です。必然的に、人々は誇大広告にうんざりし、（パラダイムの実際の有用性に関係なく）反発が発生し始めます。
今から20年後、関数型プログラミングに対する他の反動が生じることは間違いありません。
筆者の曖昧な考えを推測することは二度しかできないので、この質問に完全に答えることはできません。私はこの記事がその作者にいくらかの当惑を引き起こそうとしていることを強く疑います。 OOPについては何もありません。モジュール式でも並列でもないことを示唆しています。
モジュール性：OOPの主な側面は、それが実際にモジュール化されていることです（ただし、モジュール化は異なるコンテキストで異なることを意味します）。したがって、作者が話しているかどうかに関係なく一般化または静的プログラミング、彼は正しくありません。
Parallelization：並列プログラミングに関しては、ほとんどのフレームワークがスレッド化をサポートし、.Net Framework 4.0で見られるような適切な並列化や、OOPその上に。
関数型プログラミングとOOPは相互に排他的であると誤解されているため、作者はファッションの犠牲者になったと思います。OOP =十分に文書化されている言語。たとえば、Oliver Sturmがこの分野で公開しています。
著者は、OOPは新入生のプログラマが理解するのが難しすぎることであり、真実かもしれません-CMUの入学要件を考えると、疑わしいかもしれません！純粋な関数型言語と比較すると、狭いコンテキストでは真実ですが、パラダイム全体を非難することはほとんどありません（これは、それを使用する方法を知っている人にとってはうまく機能するようです）。
提案されたカリキュラムでは、関数型プログラミングを1つのクラスで、命令型（手続き型）プログラミングを別のクラスで、データ構造を別のクラスで教えます。新入生がこれら3つのことをマスターしたら、彼/彼女はOOPを学ぶ準備ができているはずです。
個人的にはそれはやり過ぎだと思いますが、学者たちは新しい極端なことを試してみたいと思っています。相殺として、MITは、1つの新入生クラスですべての主要なプログラミングパラダイムを教えるために使用されていました（まだ使用されている可能性があります）。
奇妙なことに、どちらの学校も本当に優れたプログラマーを輩出しています。図を行きます。