web-dev-qa-db-ja.com

デザインパターンをいつ使用するかをどのように知っていますか?

誰もがGoFの本を読んで、デザインパターンとその使用方法を学ぶことができますが、デザインパターンが問題を解決するタイミングを把握するプロセスは何ですか?パターンの知識が設計を促進しますか、それともパターンを使用して設計を変更する方法を見つけ出す方法はありますか?

言い換えれば、パターンのパターンはありますか?

63
Robert S.

設計パターンは、構造を提供することになっています問題を解決できます。実際の問題を解決するとき、設計パターンに適合するかどうかを確認するために、その問題の解決策の多く小さなバリエーションを考慮する必要があります。特に、設計パターンを適合させるために、問題またはその解決策を一般化する必要があるでしょう。

答えは、芸術です。 知識設計パターンは確かに重要なステップです。この種のことに慣れる1つの方法は、パターンだけでなく、デザインパターンのapplicationsを調べることです。 1つのパターンのさまざまなアプリケーションを見ると、時間の経過とともに、タスクをパターンにマッピングするのに役立つことがあります。

37
EfForEffort

O'Reillyから Head First Design Patterns を読むことを強くお勧めします。これは、これらのパターンを実際の世界でどのように使用できるかを説明しています。

Head First Design Patterns

また、パターンを念頭に置いて設計しすぎないようにしてください。さらに、パターンが解決に役立つ可能性のある「コードのにおい」を探します。

39
BigJump

ほとんどの人が理解できないパターンの基礎となるコアコンセプトがあります。それらをデータ構造またはアルゴリズムと考えないでください。

代わりに、あなたのコードを、メモを渡す、手紙を送るなどのメッセージを互いに送信する人々と考えてください。各オブジェクトは「人」です。

「人」と彼らがお互いにメッセージを送信するために使用するパターンを整理する方法がパターンです。

12
kyoryu

質問を裏返します。作成するパターンmtchは「どのパターンが私の問題に適合するか」です。配列内の要素を見つける、本当に単純なパターンを考えてみましょう。 Cでは、それは次のようなものです

TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ;        // Your index variable

for(ix=0; ix < SIZE; ix++){
    if (ary[ix] == item) {
       return ix ;
    }
}

コードを見て「どこで使用できるか」とは思わず、問題を見て「配列内の要素を見つける方法を知っていますか?」と言います。

より広範なパターンでは、実際に同じように機能します。頻繁に変更されないデータ構造のコピーを多数持つ必要があります。これにより、「フライウェイト」と思われます。ネットワーク境界の両側に存在する何かが欲しいと、あなたはプロキシと思います。

パターン、特にGoFを勉強するとき、「このパターンが必要な状況は?このパターンを以前に見たことがありますか?これを以前の仕事で何に使うことができましたか? 」

11
Charlie Martin

デザインパターン?あなたはそれらに浸っています!

デザインパターンについて特別なことは何もありません。デザインパターンにすぎません。すべての開発はデザインパターンを使用します。オブジェクト指向プログラミングには、一般的に望ましいと見なされ、標準的なデザインパターンになったデザインパターンの特定のセットがあります。しかし、多くの望ましくないデザインパターンや無関心なデザインパターン( design anti-patterns など)や、未発見のパターンや文書化されていないパターンもあります。

プログラミング時にパターンの使用を避けることはできません。ただし、使用しているパターンと、特定のパターンが有用な場合とそうでない場合について、より意識することができます。 GoF本 からの標準的なデザインパターンの研究は、 コードの匂いとリファクタリング について学ぶのと同様に役立ちます。特定のデザインまたはデザインパターンをいつ使用するかについての正しい答えはありません。いつ、どこでどのパターンを使用するかを知るために、それらを使用および実装する経験を積む必要があります。

7
Wedge

経験。パターンと実際の使用例について学びます。デザインを決定するたびに、知っているパターンが適用されるかどうかを考えてください。時間が経つにつれて、あなたは良くなり、パターンをより広範な問題に適用する新しい方法を発見します。

6
David Thibault

私が見つけたもう一つの素晴らしい本は:

パターンへのリファクタリング

既存のコードをいつ、どこで、どのようにパターンに変更できるかを示すことで、概念の理解が深まり、それらをどこで使用できるかを特定できるようになりました。

4
mwjackson

Rian van der Merweは、2012年6月にSmashing Magazineでこれについて excellent article を書きました。ここにいくつかの顕著な箇条書きがあります。

デザインパターンは、次の2つの理由で役立ちます。

  1. 既に解決されている問題を解決する必要がないため、パターンは時間を節約します。
  2. パターンはWebを使いやすくします。デザイナーの間で採用が進むと、ユーザーは物事の仕組みに慣れて、一般的なデザイン要素に遭遇したときの認知的負荷を減らすからです。

van der Merweは、次の場合にパターンを破ることを検討することをお勧めします。

  1. 新しい方法は経験的にユーザビリティを改善します、または
  2. 確立された方法は時代遅れになります。
4
John Horstman

パターンを知っていれば、それらはツールボックスのツールになります。タスクを見るときは、ツールから選択します。その時点で、どのツールが特定の問題に最適であるかについて、かなり良いアイデアを持っているはずです。ここで数式が機能しなくなり、実際にエンジニアリング作業を行います。

3
Bill K

Ifステートメントをいつ使用するかをどのように学びましたか?

なぜなら、それをより効果的に使用する前に、その構造を理解しておく必要があるためです。 ifステートメントは、分岐が必要なクラスの問題を解決します。ブリッジパターンは、ある種の問題を解決します。私はそれらを全く違った見方はしていません。

3
Jason Punyon

パターンを学ぶだけでは十分ではないことに同意します。ほとんどの本の問題は、実際の例を提供していないことです。先ほど提案したように、Head First Design Patternsは良いものだと聞きました。

もう1つは、ほとんどの本は意図的に言語固有ではないため、あなたにとって良いことでも悪いことでもあります。ただし、一般的なパターンを理解することは重要です、それを適切に実装する方法を知ることも同様に重要ですC#3.0 Design Patterns と呼ばれる本に出くわしました。この本は、これらの分離不可能な側面の両方にほぼ等しいインクを当てています。

2
petr k.

設計パターンの概念は、ソフトウェアエンジニアリングの多くのプラクティスと同様に、構造工学から取り入れられています。構造の構築を検討する場合、設定された目標を達成するためにその構造を構築する方法について決定を下す必要があります。これらの決定を行うとき、作業するための一連の要件があります。ブリッジは一度にXトンをサポートできる必要があるか、風などの十分な動きを可能にする特定の引張強度を持たなければならないような単純なものかもしれません。彼/彼女は最初から問題を解決しようとする可能性は非常に低いでしょう。

ソフトウェアエンジニアリングとデザインパターンはまったく同じです。それらは、一般的な問題に対する単純な一般的な解決策です。設計パターンを知っている場合、設計を進めているときに、システムの特定の部分に、使用している設計パターンに適合するものが必要な場合、それを使用します。システムを設計パターンに合わせようとせず、設計パターンをシステムに(それらが適合する場所に)合わせようとします。それらを、必要な設計作業の量を減らすためのソリューションのセットと考え、できるだけ多くの設計パターンを詰め込むようにソリューションを過剰に設計することに注意してください。これは、ソリューションを維持できず、おそらく非常にバグが多いものになります。

2
Codemwnci

デザインパターンに最初に出会ったとき、私はこれと同じ質問をしました。私は概念を評価しましたが、いつ、どのようにそれらを適用するかを知りませんでした。私の最初のアプローチは、設計段階で適用性を探すことでした。ブロック図と各ブロックの責任を半明確にしたら、責任を負い、適切な参考書でそれらを相互参照するのはそれほど難しくありません。いくつかの良いものがここで言及されましたが、GoFがあなたのリストに載っていなければなりません。次のステップは、パターンで見たものに基づいて、設計の改善を探すことです。

2
AdamC

設計パターンは、一般的な説明の解法です一般的な問題次の2つに注意する必要があります。

まず、それは一般的な説明;それは具体的な解決策ではなく、完全なレシピでもありません。一般的な問題に取り組むための解決策がどのように見えるかについての説明にすぎません。

第二に、問題は一般的な問題:です。これは、この問題が何度も何度も発生したことを意味します人々がこの一般的に繰り返される問題に理想的な解決策をどのように適用できるかについての説明を開発した時代。

そのため、一般的ではない新しい問題が発生した場合は、デザインパターンを使用して解決しないか、少なくともデザインパターンをツールにして、直面するあらゆる種類の問題を解決しないようにしてください。

0