OOPは実世界で支配的なプログラミングモデルですか？

オブジェクトはありませんか？まあ、ほとんどこれまで

ACMのコミュニケーションのVIEWPOINTセクションで、「Objects Never？Well、Hardly Ever」という興味深い記事を見つけました。これは、オブジェクトファーストまたはオブジェクトレイトとは根本的に異なる視点です。彼は「オブジェクト-決して」または多分「オブジェクト-大学院」を提案します。

著者はOOPについて話し、OOPが実際のプログラミング環境でどのように使用されるかについて質問しました。彼は、OOPは支配的なプログラミングモデルではないと考えています。たとえば、プログラミングの70％は、OOPがあまり適していない組み込みシステム向けに行われていると彼は言います。

大学の一部の教授は、OOPの利点について話したい場合、コードの再利用について話します。別の例として、再び、彼は、これは現実世界の実際のケースではない、と主張します。コードの再利用は大学で主張されているものよりも難しい：

OOPの使用は、ほとんどの人が信じているほど普及しておらず、支持者が主張するほど成功していないため、CSカリキュラムの中心的な位置は正当化されないと主張します。

スタックオーバーフローの人々がこれについてどのように考えているかを知るのは興味深いですか？OOPは、プログラマーの観点から見れば、主要なプログラミングモデルですか？

アプローチを1つだけ選択/学習/使用する必要がある場合、それはOOPですか？どうして？

ACMのコミュニケーションのVIEWPOINTセクション

実用的なプログラミングに興味がある場合は、ACMや同類の議事録が最後に読みたいソースです。これらは、多くの場合[現実]科学的出版物であり、現実の世界には適用されません。これらは非常に頻繁に宣伝のために作られた非正統的な意見であり、作家は群衆から自分自身を差別化し、自分の人を宣伝します。

OOPの使用は、ほとんどの人が信じているほど普及しておらず、支持者が主張するほど成功していないため、CSカリキュラムの中心的な位置は正当化されないと主張します。

私はあなたの主張に反対する傾向があります。OOPは広く普及しており、問題なく機能しています。OOPベースのプロジェクトの数は、他の戦略で行われた開発を上回る可能性があります（15〜20年の現代について話しましょう）。

ただし、OOPは特効薬ではありません。一部の開発では機能しますが、他の開発では機能しません。他のアプローチと同じです。

しかし、言及しなければならないことの1つは、カリキュラムがさまざまなアプローチの知識を伝えるべきだということです。OOPベースの場合、それは間違っています。FPベースの場合、それは間違っています。それらすべてをカバーするか、このトピックにまったく触れないでください。

PSどうして支配的なものとそうでないものを気にするのですか？手元のプロジェクトに適したものを取り、その数字を「研究者」にお任せください。

OOPがあなたが知っている唯一のパラダイムであるなら、もっと学ぶべきでしょう。しかし、実際には、OOPとは実際にはどういう意味ですか？JavaまたはC ++を意味しますか？Smalltalkを意味しますか？設定可能な値スロットとクロージャーを意味しますか？（こんにちは、Scheme！）それはメッセージ送信を意味しますか？（こんにちは、アーラン！）

要するに、質問するのは面白くない質問のようです。「オブジェクト指向は便利ですか？」より良い質問です。そして、そうですね。（確かにそれは私のためです。）

すべての開発者は、「プログラミングの70％」をどこで行っていますか？私が知っているすべての開発者のうち、組み込みシステムに取り組んでいるのは1％未満です。

したがって、3つのオプションがあります。

1. 私はユニークで、あなたの友達全員が本当に組み込みプログラミングをしています
2. 地下室に閉じ込められた開発者の軍隊がどこかでそれらの70％をやっている
3. この統計は構成され、記事はでたらめです

オプション1または2が実際に真であるという証拠を確認しない限り、オプション3を使用します。

（ところで、私は現代のモバイル開発の組み込みプログラミングを考慮しておらず、すべてのAppleが* Objective * Cを使用してiPhone用に開発することを強制した後、モバイル開発は多くの場合OOです）

フォローアップする事実はありませんが、OOPは主要なプログラミングモデルではありません。ビジュアルベーシックコースを受講したか、Excelでマクロプログラミングを行った人が開発した社内アプリをすべて想像してみてください。

多くのアプリケーションは、すべてのロジックが単一のクラスまたはビューに積み重ねられる命令型プログラミングを実行しています。これはおそらく、企業全体で実行される内部の単純なアプリケーションの大部分です。

それには何の問題もありません。同じ問題を解決する方法はいくつかあります。他のものよりも適しているものもあります。

また、指摘したように、OOPはすべてのシナリオに役立つわけではありません。他のモデルもあります。

OOPが主要なプログラミングモデルであるかどうかは関係ありません。異なるモデルを異なるケースに適合させるだけです。

特効薬はありません。

モティ・ベン・アリが議論しているのは学術的主張であり、すでに無意味です。しかし、彼は、OOPが「意味をなす」ことは一度もなかったと述べています。明らかに、何千人もの開発者やソフトウェアエンジニアがそうであり、多くのシステムで使用されています。

しかし、本当に私の答えのポイントはこれです、あるモデルまたは別のモデルが支配的であるかどうかを述べることは良いことです、それはそれを盲目的に使用するための良い根拠ですか？もちろん、そうではありません。

これは実際、確実に答えるのが難しい質問です。最大の理由は、コードが私たちの建物を離れることのないカスタムの社内アプリケーションで働く私のような人々です。ここでオブジェクト指向を使用しますか？私は言っていません。他に何人のプログラマーが同様の仕事をしていますか？彼らは言っていない。求人サイトはありますが、すべての求人が掲載されているわけではありません。また、すべての求人が実際の求人向けではなく、リクルーターが名前のリストを収集しようとしています。

私が作業するオブジェクト指向を使用すると言ったとしても、それはリンクされた記事からの伝統的な定義を意味します：オブジェクト、クラス、継承？それとも、コードを整理する手段として主にオブジェクトを使用するということですか？それとも、実際にインターフェイスにプログラムし、継承をほとんど使用しないということですか？私はまだ言っていませんが、これらのどれが本当にオブジェクト指向としてカウントされますか？

上記の質問が回答されるまで、OOが有用かどうかを尋ねることは意味がありません。

もちろん、それは最新の流行語であるため、経営陣はそれを把握しています。また、命令型プログラミングよりも優れたカプセル化と抽象化を提供するため、oopから次に来るものへの飛躍には、oopが命令するよりもさらに時間がかかると思います。

PS2：アプローチを1つだけ選択/学習/使用する必要がある場合、それはOOPですか？どうして？

1つだけを学習する場合は、別のフィールドを選択する必要があります。

型とカプセル化、およびOOPのその他すべての利点について学習し、機能スタイルのプログラミングを使用してこれらの同じことを達成する方法を学習する必要があります。

OOPは間違いなく、実際の世界で最も支配的なプログラミングモデルの1つです。

デジタルハードウェアを設計する人々であるチップ設計者自身でさえ、SystemVerilogとSystemCのデュオに移行しています。これらはオブジェクト指向プログラミング言語です。

OOPはどこで使用されませんか？デバイスドライバーをコーディングしている場合、汎用プログラミングまたは多重継承が必要な理由を想像するのは困難です。または、AI関数型プログラミング手法を実行している場合、頭の中でずっと簡単になります。他にも多くの状況がありますが、OOPはoligo占的なプログラミングの世界では非常に強力な場所であると言えば十分です。

私はノーと言います。

「オブジェクト指向」言語を使用して書かれた膨大な量のコードがあることは理解していますが、一般的に、コードはクラスで手続き型にまとめられているだけです。（これは必ずしも悪いことではありません）。私が見たこれらの言語でよりオブジェクト指向になるように書かれたコードは、通常維持できないクラス間の依存関係の恐ろしい混乱である傾向があります。

OOは完全に自己完結型のオブジェクト間でメッセージを渡すことを想定しているため、今日のコードではそれよりもはるかに粒度の高いレベルで見ることができます。つまり、これらのオブジェクトはdllまたはアセンブリまたはCOMオブジェクトとして実装されています。「コンポーネント」と言われているのを聞いたことがあります。

したがって、OOが使用されているかどうかは本当に問題ではないと思います-コードがその寿命の間に維持可能で、設計された範囲で再利用可能で、開発が迅速であれば、気にしません純粋に手続き型または半オブジェクト指向または完全オブジェクト指向の場合。支配的なスタイルがこれらのいずれかであるかどうかを誰もあなたに伝えることはできないと思いますが、関数の代わりにクラスに切り刻まれたとしても、手続き型が最も一般的であると推測するのは危険です。

オブジェクト指向アプローチとオブジェクト指向パラダイムを使用して実装されたソリューションを適用することで得られるソリューションを差別化することが重要だと思います。優れたオブジェクト指向ソフトウェアについての私の意見は、両方のソリューションを組み合わせることです。オブジェクトを考え、オブジェクトの定義と相互作用を尊重し、この構造を使用するように問題を調整できる場合、柔軟で堅牢なコードが得られます。しかし、手続き型のパラダイムを使用してコードを解決するためにオブジェクトを使用する場合、Objectsの長所を活用しない厄介なミックスになります。

私は自分のコードがオブジェクト指向であることを本当に望んでおり、最初は良い構造を作成するのが少し面倒になるかもしれないことに気づきましたが、今日の柔軟性とクライアントのフラッシュ要件に対処するとき、それは価値があると思います努力。

正確な数字を知っているふりをしたり、大まかな推測をしたりするふりはしませんが、OOPを含まないプログラミングプロジェクトは数多くあります。私は産業用ロボットを使用しています。プログラムは、かなり単純で単純な手続き型コードである傾向があります。実際のロボットオペレーティングシステムはさらにそうです。

使用している「ツール」の多くはOOPベースですが、ロボットコントローラーではなくPC上で実行されます。これらには、エディター、シミュレーション、およびユーティリティが含まれます。