デザインパターンを研究するには？[閉まっている]

デザインパターンについて4〜5冊の本を読みましたが、それでもデザインパターンの中間レベルに近づいたように感じませんか。

デザインパターンを勉強するにはどうすればいいですか？

デザインパターンの良い本はありますか？

私はこれが経験だけ​​で来ることを知っていますが、これらを習得する方法があるに違いありませんか？

最善の方法は、それらを使ってコーディングを始めることです。デザインパターンは、それらについて読むだけでは適用するのが難しい優れたコンセプトです。オンラインで見つけた実装例をいくつか取り、それらを中心に構築してください。

優れたリソースは、Data＆Object Factoryページです。それらはパターンを検討し、概念と実世界の両方の例を示します。彼らの参考資料も素晴らしいです。

私は3冊の本を読みましたが、OReillyのHead First Design Patternsを読むまで、パターンをよく理解していませんでした。この本は私の目を開き、本当によく説明しました。

そのような古い質問に対する私の2セント

一部の人々はすでに言及し、実践し、リファクタリングしています。私はパターンについて学ぶ正しい順序はこれだと思います：

1. テスト駆動開発（TDD）を学ぶ
2. リファクタリングを学ぶ
3. パターンを学ぶ

ほとんどの人は1を無視し、多くの人は2を実行できると信じており、ほとんどすべての人が3にまっすぐ進みます。

私にとって、ソフトウェアスキルを向上させるための鍵はTDDを学ぶことでした。苦痛で時間がかかるコーディングには長い時間がかかるかもしれませんが、最初にテストを作成すると、コードについてよく考えるようになります。クラスが定型文を必要とする場合や簡単に壊れる場合は、悪臭に非常に早く気づき始めます

TDDの主な利点は、コードをリファクタリングする恐れがなくなり、独立性が高く、まとまりのあるクラスを作成しなければならないことです。一連の優れたテストがなければ、壊れていないものに触れるのはあまりにも苦痛です。セーフティネットを使用すると、コードへの大幅な変更を実際に体験できます。それが、あなたが本当に実践から学び始めることができる瞬間です。

さて、パターンについての本を読まなければならないときが来ました。私の意見では、それは時間をかけすぎて、一生懸命に努力しすぎていることです。私が同じようなことをしたことに気づいた後、私はパターンを本当によく理解しました、またはそれを既存のコードに適用することができました。安全テストやリファクタリングの習慣がなければ、私は新しいプロジェクトまで待っていたでしょう。新しいプロジェクトでパターンを使用する際の問題は、パターンが実際のコードにどのように影響したり変更したりするのかが分からないことです。ソフトウェアパターンを理解したのは、コードをそれらの1つにリファクタリングした後だけであり、コードに新しいものを1つ導入したときはありません。

Derek Banasが、私が大好きなパターンをデザインするためのYouTubeチュートリアルを作成しました。

http://www.youtube.com/playlist?list=PLF206E906175C7E07

彼らは少し短いかもしれませんが、彼のタイミングとプレゼンテーションは彼らが学ぶことをとても楽しいものにします。

練習、練習、練習。

あなたは何年もチェロを演奏することについて読むことができますが、それでも楽器に弓をかけて音楽のように聞こえるものを作ることはできません。

設計パターンは高レベルの問題として最もよく認識されています。それらが有用であると認識するために必要な経験がある場合にのみ関連するもの。それらが有用であることを認識するのは良いことですが、それらが適用されるか、適用された状況を見ていない限り、それらの真の価値を理解することはほとんど不可能です。

それらが役立つのは、他のコードのデザインパターンを認識するとき、またはパターンとよく合うデザインフェーズの問題を認識するときです。次に、正式なパターンを調べ、問題を調べ、それらの間の差分、およびパターンと問題の両方について何が言っているかを判断します。

これはコーディングと同じです。K＆RはCの「バイブル」かもしれませんが、カバートゥカバーを数回読んでも実際の経験は1つではありません。経験に代わるものはありません。

練習練習練習。4冊から5冊の本は、ある程度の練習をしなくても、過度の読書練習だと思います。これを行う最良の方法は、パターンを使用して現在のプロジェクトのリファクタリングを開始することだと思います。または、積極的に取り組んでいるプロジェクトがない場合は、独自の方法で行い、パターンにリファクタリングしてみてください。

あなたが彼らが解決する問題に苦しんでいないなら、あなたはそれらを完全に感謝することはできません。そして、それらは銀の弾丸ではないことを覚えておいてください-あなたはそれらを覚えて、その場で適用するために強く押す必要はありません。私の2セント

次の質問を自問してください。

彼らは何をしますか？

それらは何を分離/結合しますか？

いつ使用すべきですか？

いつ使用しない方がいいですか？

欠けている言語機能によって、それらはなくなるでしょうか？

それを使用することによってどのような技術的負債が発生しますか？

仕事を終わらせる簡単な方法はありますか？

解決する問題と、問題が実装された他の（悪い）方法を理解するまで、いくつかのパターンの利点を理解または理解するのは少し難しいことがわかりました。

GOFとPOSAの本を除いて、私はまだ何も読んでいないので、他の推奨事項をお伝えすることはできません。実際には、問題のドメインを理解する必要があるだけです。経験の浅い開発者の多くは、パターンのメリットを理解できないかもしれません。これは彼らにとっては軽微ではありません。最初に貧弱な代替案と格闘する必要がある場合、良い解決策を採用、理解、評価する方がはるかに簡単です。

幸運を

多くの良い例が与えられました。追加したいのですが：

それらを誤って適用します。これを意図的に行う必要はありません。最初のデザインパターンフィットでそれらを適用しようとすると発生します。その間、目にするすべての問題は、1つの設計パターンに正確に適合するように見えます。多くの場合、問題はすべて何らかの理由で同じ設計パターンに適合しているように見えます（シンゲルトンがその主要な候補です）。

そして、あなたはパターンを適用し、それは良いでしょう。そして数か月後、コードを変更し、その特定のパターンを使用することがそれほど賢くないことを確認する必要があります。自分を隅までコーディングし、再度リファクタリングする必要があるからです。

確かに、これは実際に21日間で学ぶことではありませんが、私の経験では、問題についての洞察が得られる可能性が最も高くなります。

Allan Shallowayによる「デザインパターンの説明」を読んだことがありますか。

この本は、パターンのカタログではないため、他のデザインパターンの本とは大きく異なりますが、主に、パターンに簡単にマッピングできる問題空間を分解する方法を示します。

問題は2つの部分に分解できます。一般的なものと異なるものです。これが完了すると、一般的なものをインターフェイスにマッピングし、実装によって異なるものをマッピングします。本質的に、多くのパターンがこの「パターン」に該当します。

たとえば、Strategyパターンでは、一般的なものは戦略のコンテキストとして表現され、可変部分は具体的な戦略として表現されます。

この本は、私にとって、電話帳を読むのと同じ程度の興奮を持っている他のパターンブックとは対照的に、非常に刺激的であると思いました。

Gang of Fourの本を試しましたか？

設計パターン：再利用可能なオブジェクト指向ソフトウェアの要素

本の場合は、「デザインパターンの説明」と「ヘッドファーストデザインパターン」をお勧めします。これらのパターンを実際に学習するには、既存のコードを調べる必要があります。すでに使用しているパターンを探します。コードのにおいを見て、どのパターンでそれらを解決できるかを見てください。

私はいくつかのデザインパターンディスカッショングループ（私たちのサイト）を主導し、5〜6個のパターンの本を読んだことがあります。Head First Design Patternsの本から始め、ディスカッショングループに参加または開始することをお勧めします。Head Firstの本は最初は少しHasboroに見えるかもしれませんが、ほとんどの人は1、2章を読んだ後にそれを気に入っています。

優れたリソース-Joshua KereiviskyのA Learning Guide to Design Patternsをパターンの順序付けに使用し、ディスカッショングループを支援します。経験から、私が注文に提案する1つの変更は、戦略を最初にすることです。今日の開発者のほとんどは、ファクトリーの優れたまたは悪い化身を経験しているため、ファクトリーから始めると、パターンについて多くの会話と混乱が生じる可能性があります。最初の会議。

HeadFirst DesignPatternをお勧めします。本を読むだけでは十分ではありません。必要な概念を取り入れた後、多くの質問に対する答えを見つけて、これらのパターンを使用できる実際のアプリケーションを見つけようとします。私は同じことをしていて、それらの質問がばかげて見えても質問を始めました。

私の提案は、それらのいくつかを実装し、それらのいくつかの実装を分析することの組み合わせです。たとえば、.Net内では、データアダプターを見るとアダプターパターンが使用され、フレームワークを少し掘り下げるといくつかのパターンが使用されます。

最高の本は知りませんが、純粋主義者は「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素」と言うかもしれません

私の個人的なお気に入りとしては、O'Reillyから出版されたHead First Design Patternsが好きです。それは私にアピールする会話の声で書かれています。それを読んだとき、同時にソースコードをレビューして、それが読んでいるものに適用されるかどうかを確認しました。もしそうなら、私はリファクタリングしました。これが私が責任の連鎖を学んだ方法です。

練習-練習-練習。

デザインパターンは単なるツールであり、ライブラリ関数のようなものです。それらが存在し、おおよその機能がわかっている場合は、必要に応じて本からそれらを掘り出すことができます。

デザインパターンには何の魔法もありません。優れたプログラマーであれば、本が出る前にそれらの90％を自分で見つけました。ほとんどの場合、本は、さまざまなパターンの名前を単純に定義するときに最も役立つと思うので、それらをより簡単に議論できます。

私が設計パターンを学んだ方法は、本当にひどいソフトウェアをたくさん書くことです。私が12歳のとき、何が良かったか、何が悪かったのかわかりません。スパゲッティコードの山を書いたところです。次の10年かそこらの間、私は自分の過ちから学んだ。私は何が機能し何が機能しなかったかを発見しました。私は一般的なデザインパターンの大部分を独自に発明したので、最初にデザインパターンとは何かを聞いたとき、それらについて学ぶことに非常に興奮しました。（10年間で自分にC ++を教えることについての冗談は、実際には冗談ではありません）

物語の教訓：たくさんのコードを書いてください。他の人が言ったように、練習、練習、練習。現在のデザインがなぜ悪いのかを理解し、より良い方法を模索するまでは、さまざまなデザインパターンをどこに適用するのかがよく分からないと思います。デザインパターンブックは、他の開発者とそれを議論するための洗練されたソリューションと一般的な用語を提供するものであり、理解できない問題へのペーストインソリューションではありません。

デザインパターンを読み取り、それらをコーディングする練習をするという概念は、IMOを実際に支援するものではありません。これらの本を読んだとき1.特定のデザインパターンが解決する基本的な問題を探します。クリエーションパターンから始めるのが最善の策です。2.あなたは過去にコードを書いたことがあると思います。設計パターンが解決策を提供することを目的とする同じ問題に直面したかどうかを分析します。3.コードの再設計/再ファクタリングを試みるか、おそらく最初からやり直してください。

確認できる資料について

1. www.dofactory.com
2. 設計パターン：Erich Gamma、Richard Helm、Ralph Johnson、およびJohn M. Vlissidesによる再利用可能なオブジェクト指向ソフトウェア（Addison-Wesley Professional Computingシリーズ）の要素
3. Martin Fowlerによるエンタープライズアプリケーションアーキテクチャのパターン

1はクイックスタート、2は詳細な調査です。3は、エンタープライズソフトウェアの2つの適合性で学んだことを説明するか、考えさせる必要があります。

私の2セント...

デザインパターンを学ぶのも難しいと思います。OOPと、中規模から大規模のアプリケーション開発に関するいくつかの経験について詳しく知る必要があります。私は開発者のグループとして勉強し、議論をしています。私たちは、パターン学習を完了した「パターンを設計するための学習ガイド」に従います。C＃とJavaScriptの開発者が参加しています。C＃開発者がJavaScriptでコードを記述し、JavaScript開発者がC＃コードに対して同じことをするのは、私にとっては空想的なことです。会議を辞めた後、家で何冊かの本を調べて読んでレビューします。詳細を理解し、私の心の中で覚えておくためのより良い方法は、C＃とJavaScriptの両方の例を使用してブログを作成することです（http://tech.wowkhmer.com/category/Design-Patterns.aspx）。

まず、各デザインパターンに進む前に、パターンの名前を理解しておくことをお勧めします。さらに、誰かがその概念を知っている場合は、プログラミングだけでなく、読み取りの世界での1つの例を説明してください。

例えば：

工場での方法：

世界を読む：お金を5ドル、10ドル、または20ドル与えるだけで、どのように生産されるかを知らなくてもピザが生産されます。小、中、または大規模なピザは、お金の投入に依存するので、食べたり、何でもできます。

プログラミング：クライアントはパラメーター値$ 5、$ 10、または$ 20をファクトリーメソッドに渡すだけで、Pizzaオブジェクトが返されます。したがって、クライアントは、処理方法を知らなくてもそのオブジェクトを使用できます。

これがあなたを助けることができるかどうかはわかりません。会議に参加する人々の知識レベルに依存します。

さらに別の設計変更のためにコードを10回修正しなければならなくなった後、開発者として直面した問題のいくつかを検討する必要があると思います。おそらく、やり直しや苦労がたくさんあると感じたプロジェクトのリストがあります。

そのリストから、設計パターンが解決しようとしているシナリオを導き出すことができます。異なるデータセットに対して同じ一連のアクションを実行する必要があった時期はありますか？アプリケーションの将来の機能を利用できるようにする必要がありますが、既存のクラスのすべてのロジックを作り直すことを避けたいですか？それらのシナリオから始めて、パターンのカタログと、それらが解決するはずのそれぞれの問題に戻ります。GoFとプロジェクトのライブラリが一致する可能性があります。

初心者の場合、Head First Designパターンは、すべてのパターンに慣れたら、リアルタイムオブジェクトをそれらのパターンに視覚化してみます。

この本は、基本的な概念を理解するのに役立ちます。ただし、現実の世界で実装するまでは、デザインパターンのマスターになることができません。