OOPでしか記述できない、またはそれなしでは実現するのが難しい、どのような種類のプログラム/ソリューションですか？
最近の質問を言い換えると： https://softwareengineering.stackexchange.com/questions/52608/what-is-object-directiond-programming-ill-suited-for
私は反対の質問をしたいと思います：
OOPを使わないとどんなプログラムが書けないの？
OOP以外の手法を使用して作成することが推奨されていないプログラムの種類は何ですか？
どのようなプログラムが必要かOOP書くことさえできますか？OOP？
この質問への答えは、OOPのアイデアを、コード品質に特別な関心を持たないプロジェクトリーダーに売り込むのに役立ちます。少なくとも、そのようなものを見せれば、アイデアを購入することができます。 OOPを使用しない限り不可能です。
技術的には、コンピュータサイエンスの分野ではOOPなしでは解決できない問題はありません。オブジェクト指向の原則は、一般的にソースコードのレイアウトとアーキテクチャを定義します。コードがCPUで使用するためにアセンブリ言語にコンパイルされると、OOPのパターンのほとんどが消えます。
ただし、現代の言語の多くはオブジェクト指向であるため設計であるため、OOPの組み込みサポートを利用しないような言語で記述されたプログラムは実際には、利用可能なツールを使用してプログラムを構築するよりも多くの労力が必要です。 Java/Dalvik VMや.NETCLRなどのマネージドメモリ環境では、通常、ゼロからO-Oとして設計された言語が使用され、それを回避する方法はありません。少なくとも、main（）メソッド（およびそれが呼び出すサブルーチン）を含むオブジェクトが必要です。
requireオブジェクト指向アーキテクチャのプログラムに関しては、最も近いのはイベント駆動型GUIプログラムだと思います。 GUI SDKによって提供されるフレームワークはオブジェクト指向であり、フックだけで構成されるCLRプログラムをアンマネージWindows APIコードに記述して、ウィンドウを作成および表示し、それらのウィンドウでのユーザーの入力に反応することができると確信しています。そのような試みに直面する私が提起する質問は、フレームワークがすべてのGUIコントロールを表すオブジェクトを提示するとき、それぞれがきちんとした整頓されたパッケージで基本とほとんどの高度な使用シナリオを処理するとき、「なぜ！？」です。
それはオブジェクト指向プログラミングの強み。 「ブラックボックスの概念」。実際に何かが行われる方法を気にする必要はありません。あなたは単にそれを気にしますisあなたがそれをしたいときに行われます。 Form.Show（）を呼び出すだけでよいのに、なぜ12個のWindows API関数にフックし、何百もの呼び出しを行ってウィンドウを画面に表示するのですか？
OOPが良いことであると経営陣を説得する限り、議論はすべて時間に関するものです。 OOPは、コードの再利用を増やすことで開発者の時間を節約するように設計されています。汎用コードオブジェクトすでに存在しているため、書き直す必要はありませんが導出され、特定のプログラミング問題の特定のソリューションに結合されます。これらのオブジェクトもモジュール式です（GRASPやSOLIDなどの設計原則の順守を促進するGang of Fourの設計パターンに従っている場合）。つまり、ソフトウェアに問題がある場合（バグである必要はありません。プログラムはベースで更新されます）。常に新しい要件があり、ソフトウェアの更新の理由は「問題」です。そうしないと、ソフトウェアを更新しません）、現在の動作に関与し、を表示するために変更する必要があるコードの行新しい動作は、手続き型の「スパゲッティコード」の行よりも、見つけやすく、変更しやすく、必要に応じて、大規模なものに置き換えるのも簡単です。
ソフトウェア開発では、時は金なりです。ソフトウェアソリューションの直接的な材料費（主に初期費用）はほとんどないため、ソフトウェアのコストの主な要因は、ソフトウェアを作成するのにかかる開発者の時間数です。 OOPに続いて、私はあなたを保証します、それを無視するよりも重要なプログラムのために必要な開発者時間は少なくなります。
OOPを使わないとどんなプログラムが書けないの？
チューリング完全性のため、何もありません。
OOP以外の手法を使用して作成することをお勧めしないプログラムの種類は何ですか？どんな種類のプログラムが書くためにもOOP必要ですか？OOP？
OOPは、GUIボタン、ファイル、ソケット、ロックなどの「自然な」オブジェクトがある場合に適しています。ほとんどすべての非OO言語では、ハンドルと呼ばれるこれらの不透明なオブジェクトが必要です。
OOPは、設計がデータ変換プロセスと実行に向けられている場合の不一致です。あなたはエッゲの 名詞の王国 で立ち往生しています。基本的に、あなたが動詞-可能、または動詞-erを持っているときはいつでも、OO土地で良い味の境界を越えて迷いました。
そのため、マルチパラダイム言語が最適ですOOは、すべての仕事に最適なツールではなく、他のアプローチでもありません。それだけでなく、単一のアプローチであるアプリケーションは比較的少ないです。したがって、現在私たちが行っているのは、アプリの70％に最適なアプローチを検討し、残りの30％を、デザインの悪い穀物湿地の怪物に対して恐ろしいものに靴べらをかけることです。
OOは、プログラムを整理する方法です。 OOの主張をするためには、その組織が重要であるのに十分な大きさのプログラムが必要です（はい、初心者は、それが問題になるほど大きなプログラムの経験がなくても、OOの考え方にドリルダウンされています、しかし、私がよく会う人はあなたのようで、なぜそれが良いのか説明できず、したがって、そうでないときを見ることができません）。
明らかに、それはプログラムのサイズ（どのメトリックBTWを使用するか）だけでなく、プログラムが行うことの多くにも依存します。 OOの最も簡単なケースはおそらくシミュレーターであり、OOの考え方は問題の領域に非常に明確にマッピングされているため、議論するのは困難です。実際のところ、これはOOの背後にあるユースケースの1つでした（Simulaは最初のOO言語の1つであり、すでに使用されている手法の言語サポートをもたらしましたしかし、形式化されておらず、C++はSimulaのオーバーヘッドを削減することを目的として開始されました）。
これで、OOを経験豊富なプロジェクトリーダーに販売するのに非常に苦労することになります。これは、あなたが取り組んでいることがOOメリットを補うことなく、オーバーヘッドだけをもたらします。