どのような問題に対して、オブジェクト指向プログラミングは良い選択ではありませんか？[閉まっている]

この質問にある程度触発されました：関数型プログラミングはどのような一般的な問題に適していませんか？-しかし、それでも私はいつも欲しかった質問ですが、尋ねるのは怖すぎました。

私は... でした。まあ、それは工学ソフトウェア開発とほぼ一生涯呼んでいます。その間ずっと、オブジェクト指向は常に存在していましたが（ほとんどの場合）、使用する必要はありませんでした「その方法」、またはそのパラダイムを学ぶこと。私たちは常にかなり単純なプログラム構造、ルーチン/関数/モジュールを使用してきましたが、それらのプログラムを管理する今日のベストプラクティスとは反対ですが（約300k LOCまでのプログラム、大きすぎない）、決して難しいことはありませんでした。

それで、私はあなたに尋ねたいと思いました、どのオブジェクト指向パラダイムは良い選択ではないでしょうか？手続き型プログラミングと比較して？

オブジェクト指向プログラミングは手続き型プログラミングです。オブジェクト指向をオブジェクト指向にするものは、Robert Harveyがコメントで言及しているように、オブジェクト指向が特定の方法でデータを抽象化することです（つまり、構造体で動作する関数をその構造体に束ねます）。

William Cookは、オブジェクトと抽象データ型の違いをうまく説明しています。

簡単に聞こえるかもしれませんが、データに対して実行する（多数の）操作を簡単に拡張する必要がある場合、オブジェクトを適切に適合させず、さまざまな実装を行う必要はありません。データ。とはいえ、この2つを近づけるためにできることはいくつかあります。

OOの主な価値は、システムのコンポーネント間のデカップリングを提供し、DRYコードを記述し、設計で計画する特定の種類の変更に容易に適応できることです。コストは、インダイレクションのレイヤーを追加することです。これにより、コードの推論が難しくなり、効率が悪くなり、予期しない方法（設計が提供するデカップリングによって支援されない方法）で変更しにくくなります。したがって、それが提供するデカップリングを必要としないサブ問題にとっては時間の無駄です。具体的には、DRYコードをそれなしで簡単に記述でき、OOが提供する強力なデカップリングの恩恵を受ける特定の要件の変更を予期しないのは時間の無駄です。

並行性：ロックメカニズムには問題があるようです。非常に優秀な開発者のみがプロジェクトのスレッド化部分で作業する

拡張：現在のオブジェクト指向言語がどれだけ拡張可能かわからない。Javaが悪いことだけを知っています。そのため、DSL（ドメイン固有言語）はフレームワークとして実装する必要があります。一方、Clojure（機能的）にはマクロがあります。

OOに精通していてもいなくても、ほとんどのプログラマーはコードで抽象化、情報隠蔽、インターフェースなどの概念を使用します。これらの概念は既に組み込まれているため、オブジェクト指向言語は単純にそれを容易にします。それらを自分で発明する必要はありません。

のようなコアアルゴリズムqsort()は、任意のオブジェクトの比較に抽象化を使用します。fread()インターフェイスを使用して、ストリームなどの詳細を抽象化します。

その観点から、非オブジェクト指向アプローチでより良く解決される特定の問題を思い付くのは難しいと思います。

Web API（rest、xmlprc、plain curl / wget）を介して他のシステムを組み合わせたシステムを構築するとき、OOラッパーを作成できると思いますが、明らかに便利です。使用するWebサービスが単純で、1行または2行で済む場合、オブジェクト指向は多すぎます。一方、複雑なWeb API（たとえばAmazon AWSなど）をラップしなければならない場合は、ラッパーライブラリ（Python for AWSのbotoなど）を用意しておくと便利です。

考え？

PUREオブジェクト指向言語は、多くの場合に適していません。純粋なオブジェクト指向言語であるために満たすべき基準がいくつかあるためです。見る-
ください :

しかし、最も広く使用されているプログラミング言語はマルチパラダイムです。さまざまな種類のプログラミングおよび開発の問題に遭遇するために、多くの非OO機能が組み込まれています。C ++、C＃、Java、またはRubyはすべて、OO以外の機能を備えています。そのため、pure-OOが得意でない問題に直面する可能性があります。

オブジェクト指向プログラミングを使用して、ドメインをモデル化できます。クラスを使用して、ドメインモデル内のエンティティ、集約、コラボレーション、サービスの状態と動作を表すことができます。さらに、オブジェクト間のメソッド呼び出しとプロトコルは、エンティティ間の動的な関係をモデル化できます。

技術的な問題（データベースやメッセージキューの使用、または実際、それはWebアプリケーションです）。このトピックに関する良い本は、ドメイン駆動設計です

ここで注意すべき重要なことは、上記の「エンティティ」が実世界のオブジェクトにマッピングする必要がないことです。アプリケーションのドメインの抽象的な部分を表すことができます。

それで、もしそれがオブジェクト指向プログラミングが得意であるなら; 何が苦手？さて、ドメインモデルをオブジェクトとしてうまく表現できないものは何でも。たとえば、いくつかの数学（統計、論理など）または技術（コンパイラなど）のプログラムは、さまざまなスタイルでより適切に表現できます。ビジネスワークフローアプリケーションでは、OOとカスタムDSL技術の組み合わせが、ビジネスプロセスで発生する種類の関係とイベントをモデル化するのに非常に効果的であることがわかりました。プログラムの検証と自動化されたプルーフチェックでは、その純粋な機能により、より直接的な数学的推論が可能になるため、機能的なアプローチがよく使用されます。