だから、2つの質問を連続して尋ねるのは奇妙ですが、それらはあまり関連しておらず、私はそれらを結合したくありませんでしたが、私は質問をスパムしません、私は約束します！

とにかく、私は最近の大学卒業生であり、私の教育はデザインパターンにのみ触れました...私たちはいくつかの簡単なものを実装し、もっと複雑なものがあるという事実に触れ、GoF本に目を向けるように指示されましたもっと学びたかった。私の質問は、GoFの本のパターンを学ぶ価値があるかどうかです。私にとって、問題を古典的なパターンに当てはめようとすることは常に直感に反するように思えますが、明らかに本とパターンは理由があることで有名です。彼らは私がそれらを学ぶべきであるほど十分に現れますか？

再度、感謝します！

いつものように

場合によります

設計パターンを認識できるか、利用できるかどうかについて、どの程度のOOPを実行したかによって異なります

それは、一度正しく学習したパターンを適用し、ハンマーを持ったことわざのような男に夢中にならないかどうかに関して、あなたがどれだけ規律を持っているかにかかっています

一方、5本の指！

あなたが深刻なOOPの仕事の年のカップルをやった場合、またはあなたがレール上にあなたを保つために信頼性の高いメンターを持っているか、あなただけのOOP-オタクの読書のように、すべての手段で本を購入し、それを勉強しに行きます。

パターンを知っておくと、使用するタイミングと使用しないタイミングを認識できます。

はい、あなたはそれらを学ぶべきです。

ある程度の経験を積んだ後にそれらを再訪することはさらに理にかなっています。一部のパターンでは、これは自分で発見したものであることが判明しますが、その使用法、トレードオフ、バリアントなどについてより一般的なことを学ぶことができます。他の人はあなたが対処した問題に直接対処し、あなたが知らないエレガントな解決策を示しているように見えるかもしれません。

パターンの大部分は非常に便利で一般的です。他の人はそれほど人気が​​ないかもしれませんが、それでも彼らが完璧にフィットするいくつかの狭い用途を持っています。

読む価値があるもう1つの理由があります。確かに、それは特効薬ではありませんが、それでも貴重なインスピレーションです。

最後になりましたが、決して、決して、決して、どんな状況でも、問題をパターンやツールに適合させないようにしてください。それは非常に悪いと危険な思考です！ツールがどのように機能するかを理解し、問題に対処するために賢く使用してください。

よく知っているツールが多ければ多いほど良いです。時にはツールが（問題を直接解決するのではなく）あなたの思考を刺激することがあります。また、いくつかのツールを組み合わせて優れたソリューションを得ることができます。

GOF本は、私たちが毎日使用する多くの便利なツールの素晴らしい情報源です。

デザインパターンについて少しだけ知っていることの最も重要な利点は、用語の意味を知っていることです。つまり、一般的な語彙を知っています。

これは、私にとって、すべてのデザインパターンの混乱の中で最も重要な成果であり、特定のパターンの名前を使用するだけで共通の語彙が発生し、他の人は説明せずにあなたが話していることをすぐに知っている。パターンが記述するものは、ほとんどのプログラマーによく知られていますが、他の人にあなたが何を意味するのかを説明するのに時間がかかるので、コミュニケーションがパターン名を知りやすくなります。

例は、訪問者、シングルトン、およびデコレータです。

つまり、少なくとも名前とその機能に精通することをお勧めします。

はい、ただし慎重に！

YESの部分：

時々、設計で問題が発生しました。これらの問題は非常に一般的である場合があるため、設計パターンはそれらの問題に対する十分にテストされたソリューションを提供します。設計パターンを学習する主な利点は、設計ソリューションをより迅速に思い付くことができ、同僚が設計パターンの専門用語を認識している場合、ソリューションをより迅速に説明できることです。

慎重な部分：

設計パターンは、ソリューションの聖杯であってはなりません。最も単純な（KISS）ソリューションがより望まれており、多くの場合、デザインパターンは物事をより複雑にします。デザインパターンを学習している場合は、アンチパターンについても学習します。私はデザインパターンに反対する古い人々を知っていますが、コーディング経験があまりないがデザインパターン理論の負荷が少ないと、あなたとあなたのシンをかなり難しくする可能性があるので、ある程度同意しますチーム。

最後に、設計パターンに準拠するためだけにソリューションを適合/変更する必要があるとは思わないでください。それどころか、ソリューションに適合するようにデザインパターンを曲げることができます。特定の問題に対してより良い解決策がある限り、デザインパターンレシピのすべての成分を使用していない場合でも問題ありません。設計パターンは、ソリューションのルールとしてではなく、提案として考えてください。

Net Objectivesのパターンを最も有益であると考える方法を見つけました。GoFの本を読んでいる人は、デザイン表記やコードで示している構造がパターンであり、これが常に見た目であると思い始めます。別の、おそらく間違いなくより良い見方があります。

パターンは、さまざまな問題を解決するために使用できる式のセットではなく、特定の抽象的な式ですべて解決できる同様の問題のセットです。これが意味することは、デザインを作成しようとする前からパターンがすでに存在し、デザイナーの目的はそれを見つけることであり、それを課すことではないということです。

さらに、多くの人がパターンを見て、「ああ、私はそれを...で解決しました。ばかげたパターンは使用しませんでした」と言います。問題は、「....」がほぼ必然的に特定のパターンソリューションのAN実装を説明することです。たとえば、関数ポインターの配列は、これが従来のレシピのように見えなくても、責任の連鎖として機能します。

これを念頭に置いて、パターンの研究では、パターンではなく問題に焦点を当てる必要があります。パターンの動機付け要因とそれらがそれらの要因にどのように対処するかを学びます。これを行うことで、問題のパターンを確認し、単純に指摘することができます。これは、パターンがデザインについて話すために提供する言語とともに、現在直面しているさまざまな困難に答えるのに適したデザインを公開することを可能にします。

はい、要するに、学習パターンはそれだけの価値があるだけではありません...あなたはそれらを学習しないことによってあなた自身を制限します。「私の訪問者のように見えます」と言うとき、すべての動機付けの原則とソリューションの一般的な形を説明する必要はありません。

ここに彼らのウェブサイトがあります：http : //www.netobjectives.com/PatternRepository/index.php?title=Main_Page

GoFによって記述されたデザインパターンは、OOパラダイムの自然な拡張の一種です。OOPの目標（カプセル化、懸念の分離、DRY原則、モジュール性など）を完全に理解していない場合、デザインパターンをうまく適用しようとしても意味がありません。

ただし、実際のOOPで足を濡らし、OOPの値に忠実になろうとすると、GoFで説明されているような状況に陥ることは避けられません。同様の多くの問題を解決した後、パターンが出現し始めることがあります。この時点で、本を読むことは理にかなっています。理想的には、あなたは認識の感覚を持ち、提案されたパターンの優雅さと清潔さをすぐに理解するでしょう。また、これらのパターンのいくつかを簡単に検討することもできます（一度知ってしまえば、その多くはそうです）。また、特定のパターンが特定の状況に適用可能かどうかを適切に判断することもできます。

また、別の警告があります。これらのパターンをすべて知っているからといって、それらをすべての場所に適用する必要があるわけではありません。それらのいくつかは非常に賢く、人々は恐ろしく不適切であってもそれらを使用するように誘惑されます。シングルトンのパターンは最も有名な例です-インスタンスのみの制約）。

デザインパターンは、デザインの問題を解決しようとします。

• これらは主にOOP言語向けに作成されました。
• 一部の問題は関数型プログラミングには存在しません（コマンドパターンは一流の関数を作成する方法であり、戦略パターンは高次関数を近似します...）。これらのパターンは、必要な機能を持たない言語（主にOOP）用です。
• それらはアルファベット順にソートされます。いくつかのパターンは他のパターンの構成であるか、アイデアは以前に存在したもので構成されています。

関数プログラミング、UML、データベース設計、データ構造、アルゴリズムを知った後、後でパターンを学びました。私は実際に、これらのパターンをチートシート上のデザインのリストにたどり、ほとんどのパターンを既に知っているとうなずきました。シングルトンや「コミュニケーション」パターン（訪問者、調停者）のように本当にいい人もいました...

経験の少ないデザインパターンを適用することがどのように危険であるかについて、他のいくつかの回答で指摘された点に同意します。

それでも、少なくともGoF本の最初の章を読むことを強くお勧めします。最初のセクションでは、デザインパターンを紹介しますが、実際にはオブジェクト指向デザインの原則について説明します。これは、比較的少ない経験でも読んで理解するのに役立つはずです。（私が覚えているいくつかの重要なアイデアには、「さまざまな概念をカプセル化する」、「継承階層は広くなければならないが、深くはない」が含まれます。）これらのパターンを通知することも非常に貴重です。

私の質問は、GoFの本のパターンを学ぶ価値があるかどうかです。

絶対に！ソフトウェアの設計パターンだけでなく、一般的な設計手法を学ぶ必要があります。一般的な問題の一般的な解決策を学ぶことは素晴らしいスタートです。特にパターンとそのトレードオフを掘り始めたら。

彼らは私がそれらを学ぶべきであるほど十分に現れますか？

オリジナルのGang of Fourの本は、多くのソフトウェアプロジェクトを調査し、多くの開発者が問題を解決するために使用したテクニックを見ることによって開発されました。著者は、いくつかの非常に優れた手法に気づきました。また、非常にばらばらなプロジェクトに適用されたいくつかの手法に注目し、それらを抽象化してドメインに関係なく使用できるように努力しました。

問題を古典的なパターンに当てはめようとすることは常に直感に反するように思われます

これは大きな問題です。あなたは問題を解決策に適合させません。代わりに、Gang of Fourのデザインパターンブックには各パターンの「問題」セクションがあり、他のパターンカタログには、各パターンをいつ適用するかを説明する同様のセクションがあります。また、パターンを使用することの「結果」についても説明します。結果を回避しようとしている場合、パターンを使用することは最善のアイデアではありません。