デザインパターン：学習する必要がありますか？
したがって、2つの質問を連続して尋ねるのはちょっと変ですが、それらはあまり関係がなく、それらを組み合わせたくありませんでしたが、質問をスパム送信しているわけではないので、約束します！
とにかく、私は最近の大学卒業生であり、私の教育はデザインパターンのみに触れていました...いくつかの単純なパターンを実装し、より複雑なパターンがあるという事実に触れ、もし私たちがもっと学びたかった。私の質問は、GoF本のパターンを学ぶ価値はあるのでしょうか。私にとって、問題を古典的なパターンに合わせようとすることは常に直観に反するように思われますが、本とパターンは明らかに理由があります。彼らは私がそれらを学ぶべきであるほど十分に現れますか？
再度、感謝します！
いつものように
場合によります
OOPデザインパターンを認識できるか、それとも利用できるかについて、どれだけ行ったかによって異なります
それは、一度正しく学習されたパターンを適用し、ハンマーを持つことわざのようなくだらないものにしないかどうかについて、あなたがどの程度訓練されているかに依存します。
一方、5本の指！
数年真剣に取り組んだ場合OOP仕事orあなたはRails or OOPオタクの読書が好きな人なら、ぜひ本を買って勉強してください。
パターンを知っておくと、いつ使用するか、いつ使用しないかがわかります。
はい、それらを学ぶ必要があります。
ある程度の経験を積んでから再度お読みくださいの方が理にかなっているので、知っているものと比較できます。一部のパターンでは、これは自分で発見したものであることが判明しますが、その使用法、トレードオフ、バリアントなどについてより一般的なものを学ぶことができます。他の人はあなたが対処した問題に直接対処し、あなたが知らなかったエレガントな解決策をあなたに示すように見えるかもしれません。
素晴らしいパターンの大部分は非常に便利で一般的です。他のものはそれほど人気ではないかもしれませんが、それでもそれらが完全にフィットするいくつかの狭い使用法があります。
それを読む価値があるもう一つの理由があります：それはあなたに考える方法を教えてくれます。もちろん、それは特効薬ではありませんが、それでも非常に貴重なインスピレーションです。
最後に重要なことですが、決して、いかなる状況でも、問題をパターンまたはツールに適合させようとしない。それは非常に悪い危険な考えです！ツールがどのように機能するかを理解し、賢く使用して問題に対処します。
あなたがよく知っているツールが多ければ多いほど、より良いものになります。ツールは、（問題を直接解決するのではなく）思考を刺激する場合があります。また、いくつかのツールを組み合わせて優れたソリューションを実現することもあります。
GOF本は、私たちが毎日使用する多くの便利なツールの素晴らしい情報源です。
デザインパターについて少しだけ知ることの最も重要な利点は、用語の意味を理解できることです。言い換えれば、あなたは一般的な語彙を知っています。
これは、私にとって、すべてのデザインパターンの混乱の最も重要な成果です。特定のパターンの名前をそのまま使用できる共通の語彙が発生し、他の人はあなたがそれを説明しなくてもすぐに何を話しているかを理解しています。パターンが説明することはほとんどのプログラマーによく知られていますが、あなたが他の人に何を意味するのかを説明するのに時間がかかるため、コミュニケーションによってパターン名を簡単に知ることができます。
例としては、ビジター、シングルトン、デコレーターがあります。
つまり、言い換えれば、少なくとも名前とその機能を理解することをお勧めします。
はい、ただし慎重に！
YESの部分：
ときどき、デザインに問題が発生しました。これらの問題が非常に一般的である場合があるので、設計パターンはそれらの問題に対して十分にテストされたソリューションを提供します。設計パターンを学ぶことの主な利点は、設計ソリューションをたくさんきらめきにできることと、同僚が設計パターンを知っているかどうかです。 lingoを使用すると、ソリューションをより迅速に説明できます。
慎重な部分：
設計パターンは、ソリューションの聖杯であってはなりません。最も単純な（KISS）ソリューションがより望ましく、多くの場合、設計パターンによって物事はより複雑になります。デザインパターンを学習している場合は、アンチパターンについても学習します。デザインパターンに反する古い人々を知っています。ある程度同意します。なぜなら、コーディングの経験はあまりないが、設計パターン理論の負荷が高い場合は、最終的には、シンの作成があなたやチームにとって非常に困難になる可能性があるからです。
最後に、設計パターンに準拠するためだけにソリューションを適合/変更する必要があるとは思わないでください。逆に、ソリューションに適合するように設計パターンを曲げることができます。特定の問題に対してより良い解決策がある限り、デザインパターンレシピのすべての要素を使用していなくても問題ありません。デザインパターンを提案として考え、ソリューションのルールとして考えないでください。 。
GoFで説明されているデザインパターンは、OOパラダイムの自然な拡張のようなものです。OOP（カプセル化、分離の目的を完全に理解していない場合DRY原理、モジュール性など）の懸念がある場合、デザインパターンをうまく適用しようとしてもあまり意味がありません。
ただし、実際のOOPで足を濡らし、OOPの値に忠実であるようにしようとすると、必然的にGoFで説明されているような状況に陥ります。 '彼らと同様の解決策を発明します。多くの同様の問題を解決した後、あなたはパターンが現れるのを見始めるかもしれません;この時点で、本を読むことは理にかなっています;理想的には、あなたは認識感を持ち、あなたは提案されたパターンの優雅さと清潔さをすぐに高く評価します。おそらく、これらのパターンのいくつかを簡単に検討することもできます（一度知ったら、それらの多くはそうです）。また、かどうかを適切に判断できるようになります。特定の状況では、特定のパターンが適用されない。
そしてここに別の警告があります：これらすべてのパターンを知っているからといって、どこにでもそれらを適用する必要があるという意味ではありません。それらのいくつかはかなり賢く、人々はひどく不適切な場合でもそれらを使用するように誘惑されます、シングルトンパターンは最も有名な例です（シングルトンの論争の多くは不適切な使用から生じます。 -インスタンスのみの制約）。
私は、パターンについてネット目標が最も有益であると考える方法を見つけました。 GoFの本を読む人は、デザイン表記とコードで示す構造がパターンであり、これが常にどのように見えるかを思い込みすぎることがよくあります。それを見るには別の、間違いなくより良い方法があります。
パターンは、さまざまな問題を解決するために使用できる数式のセットではなく、特定の抽象的な数式ですべて解決できる類似の問題のセットです。これが意味することは、デザインを作成しようとする前にパターンがすでに存在しているということです。デザイナーの目的は、それを見つけることです。それを課す。
さらに、多くの人がパターンを見て、「ああ、私はそれを...で解決しました。私はばかげたパターンを使用しませんでした。」重要なのは、「....」は、ほとんどの場合、所定のパターンソリューションのAN実装を記述しているということです。たとえば、これは従来のレシピとは異なりますが、関数ポインタの配列は責任の連鎖として機能します。
これを念頭に置いて、パターンの研究の焦点はパターンではなく問題にあるべきです。パターンの動機となる要因と、それらがそれらの要因にどのように対処するかを学びます。これを行うと、問題のパターンを確認して、単純にそれらを指摘できます。これは、パターンがデザインについて話すために私たちに与える言葉とともに、現在直面しているさまざまな困難に答えるのに適したデザインを公開することを可能にします。
はい、要するに、パターンを学ぶことはそれだけの価値があるだけではありません...あなたはそれらを学ばないことによってあなた自身を制限します。 「私には訪問者のように見える」と言ったとき、私はすべての動機付けの原則とソリューションの一般的な形を説明する必要はありません。
ここに彼らのウェブサイトがあります： http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page
デザインパターンは、デザインの問題を解決しようとします。
- それらは主にOOP言語用にAFAIKで作成されました。
- 一部の問題は関数型プログラミングには存在しません（コマンドパターンはファーストクラスの関数を作成する方法であり、戦略パターンは高次関数を近似します...）。これらのパターンは、機能を必要としない言語（主にOOP）用です。
- それらはアルファベット順にソートされています。いくつかのパターンは他のパターンの構成であるか、アイデアは以前に存在したもので構成されています。
関数型プログラミング、UML、データベース設計、データ構造、アルゴリズムを知った後で、後でパターンを学びました。私は実際に チートシート上のこれらのパターンのデザインのリスト を掘り下げただけで、それらのほとんどをすでに知っているとうなずきました。シングルトンまたは「コミュニケーション」パターン（訪問者、メディエーター）のように、本当に素晴らしいものもありました...
経験の少ないデザインパターンを適用することがどのように危険であるかについて、他のいくつかの回答で指摘された点にも同意します。
それでも、少なくともGoF本の最初の章を読むことを強くお勧めします。最初のセクションでは、デザインパターンを紹介しますが、OOデザインの原則についての詳細であり、これは比較的少ない経験でも読んで理解するのに役立つはずです（覚えているいくつかの重要なアイデア） 「変化する概念をカプセル化する」、「継承階層は広くても深くないべきである」を含みます。）23のパターンで作品が主に知られていることはほとんど残念です-OO =これらのパターンを通知した設計原則も非常に価値があります。
私の質問は、GoF本のパターンを学ぶ価値はあるのでしょうか？
絶対に！ソフトウェアの設計パターンだけでなく、設計手法全般を学ぶ必要があります。一般的な問題の一般的な解決策を学ぶことは素晴らしいスタートです。特に、パターンとそのトレードオフについて詳しく調べ始めたら、.
彼らは私がそれらを学ぶべきであるほど十分に現れますか？
元々のGang of Fourの本は、多くのソフトウェアプロジェクトを調査し、多くの開発者が問題を解決するために使用した手法を見て作成されました。著者は、いくつかの本当に良いテクニックに気づき、非常にばらばらなプロジェクトに適用され、ドメインに関係なく使用できるようにそれらをさらに抽象化することに取り組んだ数多くのテクニックに気づきました。
問題を古典的なパターンに適合させようとすることは常に直観に反するように見えます
これは大きな問題です。問題をソリューションに適合させません。その代わり、Gang of Four設計パターンブックには、各パターンの「問題」セクションがあり、他のパターンカタログには、各パターンをいつ適用するかを説明する同様のセクションがあります。また、パターンを使用した場合の「結果」についても説明しています。結果を回避しようとしている場合は、パターンを使用するのは最善の方法ではありません。