設計パターンが設定されているか、十分に熟練したソフトウェア開発者が各自のコードを認識して削減し、新しいパターンを開発しているか。独自の「デザイン」パターンを効果的に作成します。
編集 - 返信ありがとうございます。実際には、コードを作成する前に問題を既存の設計パターンと最初に比較する必要があるコードをリファクタリングおよび/または削減しているだけです。一致が見つかった場合は、それを使用する必要がありました。それ以外の場合は、単にコードをリファクタリングしています (これは悪いことではなく、通常、新しい一般的に有用な「パターン」を生成しません)。
それは実際にはどちらかまたは両方の質問ではありません。
設計パターンは、よく遭遇する問題に対する一般的な解決策です。
さまざまな問題 (またはさまざまなコンテキスト) に適した既存のデザイン パターンがすでにたくさんありますが、デザイン パターンの規範は閉じられていません。確かに、作成および/または検出するパターンは他にもあります。
覚えておくべき重要なことは、ソリューションが実際にパターンであるためには、再利用できるように十分に一般的である必要があり、再発する問題に適用する必要があるということです。
ほとんどのプログラマーは、時間をかけて同じパターンの多くを個別に発見していると思います。デザイン パターンのカタログの本当の目的は、特定のパターン (たとえばファサード パターン) が何であり、何をするのかを一度に全員が同意し、より高い抽象レベルでそれについて話すことができるようにすることです。
デザインパターンに関する文献を読むと、少なくとも次の種類の知識を網羅する総称であることがわかります。
一般的な問題の解決策
すべてのプログラマーが知っておくべき、つまり一般的に使用されるべき便利なプログラミング手法
一般的に使用される言語での損失の回避策（元のGang of Fourの本には、Smalltalkと比較して、C ++での損失の回避策が多数含まれていました）
デザインパターンの他の重要な側面は、プログラマーにこのことについて話すための共通の語彙を与えることです。したがって、デザインパターンであるためには、コミュニティ間で何かを共有し、合意された名前を付ける必要があります。あなたの質問に答えるために、あなたは新しいデザインパターンを作成するかもしれませんが、最初に何か新しいものを作成し、次にそれが価値がある（そしてそれを何と呼ぶか）ことにコミュニティに同意させるのは大変な作業です。
確かに、新しい問題が一般的になり、有用な新しいプログラミング手法が発明され、新しい損失が新しい回避策の必要性を生み出します。しかし、それはあまり頻繁には起こらず、新しいソリューションを発明することは大変な作業になります。Gang of Fourの本は、ほぼ完全に既存の慣習を成文化したものでした---この本の主な新しい貢献は、共有された語彙でした。それは価値のある貢献ですが、誇大広告を聞いて、新しいボトルに入った古いワイン以上のものを望んでいた私たちにとってはがっかりしました。
新しいデザインパターンを作成する場合は、よく踏まれたパスを残します。たとえば、パターンはオブジェクト指向の世界のほぼすべての場所で古いニュースです。（おそらく、マルチメソッドディスパッチまたはプロトタイプベースの言語に関するパターンの機会はまだあるでしょう。）対照的に、関数型プログラマーは、誰かが一般的なソリューションとグッドプラクティスのほとんどを識別して名前を付けるのをまだ待っています。あなたが偉大な思想家であり作家であるならば、あなたはその分野に劇的な影響を与える可能性があります。
「ギャング オブ フォー」の Design Patterns book でうまくレイアウトされているように、設定され、認識されているパターンが確かに存在します。また、Microsoft Patterns and Practices チームなどのチームが発行するCABやSCSFなどのパターンもあります。それは、すべてのパターンが網羅されているということですか？確かにそうではありません。開発者やチームは、多くの場合、ニーズを満たし、プロジェクト全体で使用する独自のパターンを考え出します。
ですから、車輪の再発明はしたくありません - すでに出回っているパターンを使用します - しかし、他の人がしていることだけに縛られているとは思わないでください.
（1）何度か必要になるまで、それは「パターン」ではありません。(2) 特定の問題領域とは独立した方法でそれを説明できます。
とは言っても、自分のやり方が許せば、新しいパターンのモラトリアムを宣言するか、文書化され、ピアレビューされ、重複しないことが示されるまで「パターン」にならない公式のパターン言語リポジトリを用意するでしょう。既存のパターン。
ほとんどの場合、人々が「パターンを作成する」と言うとき、それは再利用したいコード スニペットを見つけたという意味です。
学んだことを他の人と共有する方法として、独自のパターンとアンチパターンを文書化できない理由はありません。ただし、十分なスキルを持つすべてのソフトウェア開発者が、まだ発見されておらず、他の場所で文書化されていないものを実際に発見する可能性は低いです。このようなパターンを公開する前に、後で困惑しないように、別のパターンでこのケースがカバーされていないことを確認してください。
デザイン パターンの主な用途の 1 つは、他のプログラマーとデザインをやり取りする手段です。独自のものを作成した場合、それらに気付くのはあなただけであり、コミュニケーションにはあまり役立ちません.
通常、開発者は独自のデザイン パターンを作成します。それらを公開されたパターンに関連付けることで、新しいアイデアや洞察が得られ、コミュニケーション能力が向上します。
極端な抽象化の機会がたくさんある大規模なプロジェクトで作業していることに気付いた場合は、そうすることができます。
しかし、一般的に、デザインパターンは、ソフトウェア開発を大規模に研究するために時間を割く人々によって、多くの自他関係のプロジェクトから作成されます。
一般に、ソフトウェア設計パターンは繰り返し発生する問題に適用可能であり、プロジェクト固有のものではありません。独自の問題ドメインに対して見つけた解決策は、それらが十分に一般的であり、同様の問題を持つ同様のプロジェクトで使用できるほど再利用可能である場合、パターンと見なされる可能性があります。
ソフトウェア開発で発生する問題に対して、ますます適切に考慮されたソリューションが必要になるにつれて、パターン リポジトリは成長を続けています。