オブジェクト指向のものは本当にそれほど重要ですか？[閉まっている]

何年もの間、私はアルゴリズム関連の作業を行っており、インターネット検索用のスケーラブルなデータ構造を作成しています。情報検索関連の作業など

上記で述べたことには共通点があります。上記すべてのもの; C ++のような言語でコーディングされている場合は、それぞれ少数のクラスが必要です。私はそれらが興味深い問題であることを意味しますが、負荷の高いオブジェクト指向のものに関しては複雑ではありません。継承や仮想化などを使用したことがありません。ジェネリックプログラミングやテンプレートなどを頻繁に使用しています。

私はC ++が大好きです（-かさばるOOのもの、Erlangの作成者であるJoe Armstrongの言うところが好きなので、OO Worldではバナナを要求すると、大きなジャングルとバナナを抱えているゴリラができます）。私はJavaやPythonのような他の言語でのコーディングも楽しんでいます。

今私の質問は、私が取り組んでいるプロジェクト/アルゴリズムの種類を楽しんでいるからです。オブジェクト指向の要素を本当に学ぶ必要がありますか。継承、動的ポリモーフィズム（仮想）のようなものを使用するだけで、より優れたコーダー/デザイナーになれますか？または、関数型プログラミングの世界に移動できますか（私は今までそれを行っていません）、タスク/アルゴリズムに集中でき、名詞の王国に基づいたオブジェクト指向の要素、has-a、is-aルールを使用できないので、より魅力的です私？

簡単に言えば、OOは私が上記で言及した種類のプロジェクト/アルゴリズムについて私を助けることができますか？

編集：

ここに追加する1つの非常に興味深いリンク：

http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-nouns.html

オブジェクト指向プログラミングは、理解しやすい単語の後ろに複雑な空想的で凝ったものを隠し、自分の中の小人があなたが書いたものを実際に使用することを容易にすることを本当に得意としています。関数型プログラミングに取って代わるものではありません...実装を切り替えたり動作を追加したりするための本当に簡単な方法を提供するだけです。

上記のランダム化されたバイナリ検索ツリーの例で、エイプリルフールの日にランダマイザーをorder-by-distance-from-three-stoogesに置き換えるという要件が与えられた場合はどうなるでしょうか。メソッドを作成StoogeBinaryTree : RandomBinaryTreeしてオーバーライドするのは非常に便利なprotected int GetSortOrder (Tree a, Tree b)ので、4月2日RandomBinaryTreeに、コードを変更せずに実装をに戻すことができます。

簡単な例の1つとして、動作のごく一部を追加することと実装を切り替えることの両方を示しました...

HaskellやErlangのようにうまく機能する言語を使用してFPを実行する場合は、OOPのクールエイドを飲む必要はありません。FPは非常に強力で、現実の世界でも多くのことができます

そうは言っても、OOP言語を学ぶことは悪いことではないでしょう。プログラミングの複数の方法といくつかの方法論を理解することは、あなたにとって有利になります。さらに、HaskellまたはErlangからJavaに移行すると、REPLとラムダなしで誰でも世界でどのように作業できるのか疑問に思うはずです。

一度に1つの問題を解決することに集中しているようです。つまり、アルゴリズムの作成です。しかし、たとえばGUIアプリケーションや、アルゴリズムの多くを使用する必要がある可能性のある他の巨大なアプリケーションをどのように作成するかを検討してください。その場合、オブジェクトを読み込むことができるライブラリを作成するなど、コードを単純化して他の開発者がより読みやすく簡単に使用できるようにするため、オブジェクト指向を知ることは不可欠です。

オブジェクト指向プログラミングで最も重要な設計パターンの1つは、上記のシナリオでも非常に役立つ戦略パターンです。ユーザーがアルゴリズムの実行を許可する入力をユーザーに提示する例を考えてみます。これは簡単に厄介なif / elseまたはswitch / case構成になる可能性があります。アルゴリズムの共通インターフェースを作成し、Strategy Patternを使用することで、コードははるかに柔軟で読みやすくなり、拡張が容易になり、保守も容易になります。

オブジェクト指向のアプローチが成功したのは、1つの重要な側面がありました。偶発的な複雑さを過度に導入することなく、本質的に複雑なシステムに取り組むことができるからです。これは自作のシステムで作業する場合はほとんど無視できますが、大規模なシステムを構築する場合は非常に重要になります。

オブジェクト指向のアプローチの主要な要素は、数日のうちに手続き型プログラミングに多くの経験を持つプログラマーに説明することができます。数日：チェスの学習に似ています。駒を10分以内に移動する方法を学ぶことができますが、ゲームを習得するには何年もかかります）。

関数型プログラミング手法は、主流言語（C＃のラムダと匿名デリゲート、C ++のラムダ、さらにはJavaの匿名クラスでさえ）への言語サポートの導入により、ますます重要になっています。これらの手法を理解することは非常に役立ちますが、戦術的なスケールでより局所的な問題に対処するように設計されています。一方、オブジェクト指向の手法は、特に大規模なチームのコンテキストでは、戦略的スケールで関連性を保ちます。

関数型プログラミングを行うと、続行しないことを決定した場合でも、それはあなたにとって非常に良い経験になります。ここでいくつかの答えを読むことができるので、多くの人はそれが何であるかさえ知りません。

遅延評価や参照の透明性などの関数型言語の概念は、学ぶのにとても良いものです。特に再帰が好きなら。

例えば：

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

リストを再帰して長さを計算する非常に単純なhaskell関数です。long longよりも大きな数値に興味があり、無限リストやその他の凝ったものを使用したい場合は、関数型プログラミングを試してください。

他の人が言ったように、オブジェクト指向は業界の主要なパラダイムです。ほんの一握りのクラスで対処できるプログラムを使用して作業してきたとおっしゃいましたが、産業用アプリケーションでは、数百または数千のユースケースに対処する必要があり、オブジェクト指向は非常に信頼できることが証明されていますそして、そのような大きなコードベースを構造化するための広く理解できる方法。

あなたは関数型プログラミングについて話しますが、これはネクストビッグパラダイムの強力な候補ですが、FPはまだ業界に精通していません。特にあなたがC ++プログラマーである場合、業界は保守的であり、パフォーマンスに重点を置いたC / C ++の世界は、ハードウェアの必須の性質が非常に現実的な考慮事項と見なされる場所であることを知っておく必要があります。一般に、組み込みシステムのプログラマーは、私の経験ではFPに非常に懐疑的です。

FP が業界でより有力なパラダイムになったとしても、Haskellのような「純粋な」FP言語の形式ではなく、F＃やScalaなどのオブジェクト機能ハイブリッド言語の形式で成功するのは確かです。

つまり、そうです、オブジェクト指向の「もの」は、プロのコードベースとあなたのキャリアにとって重要です。

OOは、構造化/手続き型プログラミングもそうであったように、複雑さを処理するための大きな改善であったため、勢いを増しました。

プロジェクトのサイズが大きくなると、OOを使用するメリットが大きくなります。1KLOCプログラムの場合、どのパラダイムを使用してもかまいません。それらはすべて問題なく動作します。しかし、200KLOC +プログラムの場合、OOの競争はありません。これは、Cで200KLOCプログラムを記述できないことを意味するのではなく、誰も（あなたでも）が理解できない混乱に陥らないようにするためには、より多くの規律が必要になるだけです。それはオブジェクト指向がそのような混乱を防ぐという意味ではなく、それがそれを防ぐためにあなたの人生を楽にするでしょう。

関数型プログラミングは、以前のパターンから多少逸脱したパラダイムです。OOの場合よりもさらに複雑な処理には役立ちませんが、並列プログラミングという異なる種類の問題に対処するためです。また、プログラミングパラダイムがこれを試みたのはこれが初めてでした。以前にOOやSP / PPに存在していたすべてのメカニズムは、パラダイムの一部ではなく、OSエンティティ（スレッド、ミューテックスなど）だけでした。パラダイムルールに従ってカプセル化されます。

その点では、FPは他のFPよりもはるかに自然ですが、それは、通常問題について考える方法を逆転させる代償になります。そのため、OOと同じスケールで非常に同じ複雑さを処理する能力は限られています。

私の推測では、これは近い将来にFPの採用を非常に特殊化されたシステム、一般的にそれほど大きくないシステム、またはより大きなシステムの特殊化されたセクションに制限することです。残りは引き続きOOを使用して作成されます。開発を計画している（または開発について学ぶ）もののどれが、学習の焦点、IMOとすべきかを決定します。

ジェネリックプログラミング、テンプレートなどを頻繁に使用していますが。

間違いなく、テンプレートは単にOOPの異なる形式です。仮想関数と明示的な継承には、特定のユースケース-ランタイム、バイナリ互換性があります。テンプレートはコンパイル時の互換性です。ただし、最も基本的なレベルでは、正しいインターフェイスを提供するすべてのタイプに対して同じ機能の抽象化を提供します。ランタイム継承の過剰使用はコードの重要な臭いであり、この場合、私はあなたに同意します-それは多くの場合必要とされないだけです。

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

1つはテンプレートを使用し、もう1つは実装としてランタイム継承とクラスを使用しますが、これら2つのスニペットは実質的に同一です。どちらも、呼び出す関数を抽象化しています。あなたが代わりとき、これは自明明白であるTためstd::function<void(int)>、たとえば、。唯一の違いは、その抽象化が行われる時間です。テンプレートバージョンは関数に優れており、std::function通常はメンバー変数として使用する方が適しています。新しいコールバックが必要になるたびに新しいクラスを作成する必要はありません。

OOPはアルゴリズムに特に適していません。これは、プログラムの断片を分解する大規模な構成を対象としています。特定のデータを操作する特定のアルゴリズムを記述している場合は、クラスが必要になることはほとんどありません。

関数のアルゴリズムを作成するのは簡単で、すばらしいことです。ただし、それを超えるとすぐに、クラスが主要なメソッドとして浮上します。

はい、それは重要です。この1つの理由からです。OOPを理解することで、より優れたプログラマーになることができます。経験則として：理解することは常にあなたをより良いプログラマーにします。

is-aもクラスも継承はもちろん、OOPとは何の関係もないことに注意してください。OOPとは、依存関係の逆転原理によって定式化されているように、間接的なデカップリングです。これはFPの重要な側面でもあると主張することができます。OOPとFPの両方を研究すると、それらが実際には連続体の両面であることをますます認識するようになります。それに対するあなたの理解がより広くそしてより深いほど、あなたはより良くなるでしょう。

OOPを理解するには、Ioや、おそらくSmalltalkとRubyを試してください。

開発の世界では、言語はツールであり、プログラミングパラダイムはツールであり、ライブラリはツールです。ツールの数が多いほど、ジョブに適したツールを選択できるようになります。そのため、時間の許す限り、OO、AOP、および関数型プログラミングを学ぶことが求められます。

開発の世界は（言語、フレームワークなどに関して）どんどん大きくなっているので、すべてを学ぶことは期待できません。ただし、これらすべてのイノベーションの目標は、開発者の生産性を高め（開発のスピードと再利用性）、コードをより保守しやすくすることです（理解しやすく、拡張と変更が容易）。

あなたができる最善のことは、ターゲットを絞った継続的な学習を行うことです。あなたが今学んだ新しい何かが、あなたが予期しない方法でより良くより速く何かを完了するのを助けてくれることを願っています。

私はSteve Jobsの本を読んでいて、そこにはXerox PARCラボでSteveがSmallTalkをどのように見たかについての話があります。それは初期のオブジェクト指向言語の1つでした。OOがなければ、グラフィカルユーザーインターフェイス（GUI）のようなものを開発することは恐ろしいことでした。すべての非同期入力により、1つの「オブジェクト」または別の「オブジェクト」での作業中にタスクからタスクへジャンプすることができます。

したがって、関数型言語を使用して多くのことを実行できますが、ユースケースがあります。現実世界の問題とより相互作用するより複雑なシステムを扱い始めると、OOは優れた設計であることがわかります。