design-patterns - 設計パターンをいつ使用するかをどのように判断しますか?

Question

GoF の本を読めば、デザインパターンとは何か、そしてその使い方を学ぶことができますが、デザインパターンが問題を解決するタイミングを理解するプロセスとはどのようなものでしょうか? パターンの知識はデザインを動かしますか、それともパターンを使ってデザインを変更する方法を理解する方法はありますか?

つまり、パターンにはパターンがありますか？

score 46 · Accepted Answer

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

ヘッドファーストのデザインパターン

また、パターンを念頭に置いてデザインを試みすぎないことも付け加えておきます。さらに、パターンが解決に役立つ可能性のある「コードのにおい」を探します。

score 46 · Accepted Answer

デザインパターンは、問題を解決できる構造を提供するはずです。実際の問題を解決するときは、その問題に対する解決策の多くの小さなバリエーションを検討して、設計パターンに適合するものがあるかどうかを確認する必要があります。特に、デザインパターンを適合させるためには、おそらく問題またはその解決策を一般化する必要があります。

答えは、芸術です。 設計パターンを知ることは確かに重要なステップです。この種のことに慣れる 1 つの方法は、パターンだけでなく、デザインパターンのアプリケーションを研究することです。1 つのパターンの多くの異なるアプリケーションを確認することは、時間の経過とともに、タスクをパターンにうまくマッピングするのに役立ちます。

score 14 · Accepted Answer

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

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

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

score 13 · Accepted Answer

質問をひっくり返してください。作成すべきパターンマッチは、「どのパターンが私の問題に適合するか」です。配列内の要素を見つける、非常に単純なパターンを考えてみましょう。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 を研究するときは、「このパターンを必要とする状況は何か? このパターンを以前に見たことがありますか? 以前の作業でこれを何に使用できたでしょうか? 自分の人生のどこにこの例を見つけることができますか? "

score 8 · Accepted Answer

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

デザインパターンは特別なことではなく、単なるデザインのパターンです。すべての開発は設計パターンを使用します。オブジェクト指向プログラミングには、一般的に望ましいと考えられ、標準的なデザインパターンになっている特定のデザインパターンのセットがあります。しかし、発見されていない、または文書化されていないパターンだけでなく、多くの望ましくない、または無関係なデザインパターン (デザインアンチパターンなど) もあります。

プログラミングでは、パターンの使用を避けることはできません。しかし、使用しているパターンや、特定のパターンが役立つ場合とそうでない場合について、より意識することができます。コードの匂いやリファクタリングについて学ぶのと同様に、 GoF bookから正規のデザインパターンを学ぶことも役に立ちます。特定の設計または設計パターンをいつ使用すべきかについて、唯一の正解はありません。どのパターンをいつ、どこで使用するかを知るには、それらを使用および実装する経験を積む必要があります。

score 6 · Accepted Answer

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

score 6 · Accepted Answer

私が見つけた別の素晴らしい本は次のとおりです。

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

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

score 4 · Accepted Answer

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

効果的に使用する前に、内外を知る必要があるより大きな構造であるため、私はそれをそれに例えます。if ステートメントは、分岐を必要とする一連の問題を解決します。ブリッジパターンは、一連の問題を解決します。私は本当にそれらを別様に見ていません。

score 4 · Accepted Answer

Rian van der Merwe wrote an excellent article on this for Smashing Magazine in June 2012. Here are some salient bullet points.

Design patterns are useful for two reasons:

Patterns save time because we don’t have to solve a problem that’s already been solved.
Patterns make the Web easier to use because, as adoption increases among designers, users get used to how things work, which in turn reduces their cognitive load when encountering common design elements.

van der Merwe recommends that we consider breaking patterns when:

The new way empirically improves usability, or
The established way becomes outdated.

score 4 · Accepted Answer

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

score 3 · Accepted Answer

デザインパターンの概念は、ソフトウェアエンジニアリングの多くの慣行と同様に、構造エンジニアリングから採用されています。構造の構築を検討する場合、設定された目標を達成するために、その構造を構築する方法について決定を下す必要があります。これらの決定を行うときは、作業するための一連の要件があります。ブリッジが一度にXトンをサポートできなければならない、または風などで十分な動きを可能にする特定の引張強度を備えている必要があるのと同じくらい単純なものかもしれません。建築家は他のビルドの事前知識を使用してそれらの設計を選択します。彼/彼女は問題を最初から解決しようとする可能性は非常に低いでしょう。

ソフトウェアエンジニアリングとデザインパターンはまったく同じです。これらは、一般的な問題に対する一般的な解決策にすぎません。デザインパターンを知っている場合は、デザインを処理しているときに、システムの特定の部分で、使用しているデザインパターンに適合するものが必要な場合は、それを使用します。システムをデザインパターンの周りにフィットさせようとしないでください。デザインパターンをシステムにフィットさせてください（フィットする場所）。それらを、実行する必要のある設計作業の量を減らすための一連のソリューションと考えてみてください。また、できるだけ多くの設計パターンを詰め込むためにソリューションを過剰に設計することに注意してください。これは、ソリューションを保守不可能にし、おそらくかなりバグのあるものにするのに役立ちます。

score 2 · Accepted Answer

私が最初にデザインパターンに出会ったとき、私はこれと同じ疑問を抱いていました。コンセプトは理解できましたが、いつ、どのように適用すればよいかわかりませんでした。私の最初のアプローチは、設計段階で適用可能性を探すことでした。ブロック図を作成し、各ブロックの責任をある程度明確にしたら、その責任を引き受けて適切な参考書と相互参照することはそれほど難しくありません。ここではいくつかの優れたものについて言及しましたが、GoF のものをリストに追加する必要があります。次のステップは、パターンに見られるものに基づいて設計の改善点を探すことです。

score 2 · Accepted Answer

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

もう 1 つのことは、ほとんどの本が意図的に特定の言語に限定されていないことです。これは、あなたにとって良いことでも悪いことでもあります。パターンを一般的に理解することは重要ですが、それを適切に実装する方法を知ることも同様に重要です。私は、 C# 3.0 Design Patternsという本に出くわしました。この本は、これらの切り離せない側面の両方にほぼ同等のインクを捧げています。

design-patterns - 設計パターンをいつ使用するかをどのように判断しますか?

14 に答える 14

Related

Reference