ギャングオブフォーは「パターンスペース」を徹底的に探索しましたか？

少なくとも10年前にギャングオブフォー（GoF）のデザインパターンを初めて知って以来、これらの23のパターンは、パターンスペースと呼ぶのが非常に大きなものの小さなサンプルにすぎないという印象を持っています。この架空のパターンスペースは、一般的なオブジェクト指向ソフトウェア設計の問題に対するすべての推奨ソリューション（既知または未知）で構成されています。

そのため、既知の文書化された設計パターンの数が大幅に増加すると予想しました。

それは起こりませんでした。GoFの本が出版されてから20年以上経っても、Wikipediaの記事には12個の追加パターンしかリストされていません。（特定のトピックを扱っているため、ここでは同時実行パターンを含めませんでした。）

その理由は何ですか？

• GoFのパターンセットは、実際には私が考えているよりも包括的ですか？

• 新しいパターンを見つけることに興味がなくなったのは、おそらくそれらがソフトウェア設計にあまり役に立たないことがわかったからでしょうか？

• 他に何か？

この本が出たとき、多くの人々がそのように考え、「パターンライブラリ」や「パターンコミュニティ」を作成するための多くの努力がありました。あなたはまだそれらのいくつかを見つけることができます：

• 「パターンコミュニティ」、WikiWikiWeb
• 「ニューヨーク市のデザインパターン研究グループ」、産業ロジック
• 「パターンカタログ」、ヒルサイドグループ

しかしその後...

新しいパターンを見つけることに興味がなくなったのは、おそらくそれらがソフトウェア設計でそれほど有用ではないからでしょうか？

これ、とても。デザインパターンのポイントは開発者間のコミュニケーションを改善することですが、さらにパターンを追加しようとすると、すぐに人々がそれらを覚えられない、間違った記憶をする、正確にどのように見えるべきかについて意見が分かれないポイントに到達します、そしてコミュニケーションは実際には改善されていません。GoFパターンではすでに多くのことが起きています。

個人的には、さらに先に進みます。ソフトウェア設計、特に優れたソフトウェア設計は、パターン、特に人々が実際に覚えることができる少数のパターンで意味のある形で捉えるにはあまりにも多様です。ほんの一握り以上を本当に覚えています。だから彼らはあまり役に立たない。

そして、あまりにも多くの人々がこのコンセプトに夢中になり、どこにでもパターンを適用しようとします。通常、結果のコードでは、すべての（完全に意味のない）シングルトンと抽象ファクトリーの間で実際のデザインを見つけることができません。

私は、これらの23のパターンは、パターンスペースと呼ぶのが好きな、もっと大きなものの小さなサンプルに過ぎないという印象を持っています。

これは、初心者のプログラマー、つまりソフトウェアパターンをつなぎ合わせるだけでプログラムを作成できると考えているプログラマーによって広まっている恐ろしい仮定です。それはそのようには機能しません。このような「パターンスペース」がある場合、そのサイズは事実上無限であると想定できます。

（GoFの意味での）デザインパターンの目的は1つだけです。使用しているプログラミング言語の欠陥を補うことです。

設計パターンは普遍的でも包括的でもありません。表現力豊かな別のプログラミング言語に変更すると、GoFブックのパターンのほとんどが不要になり、望ましくなくなります。

ここでは、3つの要因が関係していると思います。

クリティカルマスの欠如

まず、パターンは基本的に、特定の「チャンク」機能を実装するコードに名前を付けることとほとんど同じです。名前が本当の価値を提供する唯一の方法は、名前の意味を知っているすべての人に頼ることができれば、名前を使用するだけで、コードについてすぐに多くのことを理解できることです。

パターンは、それを達成するために必要な臨界質量を決して確立しませんでした。それどころか、AAMOF。GoFの本が出版されてから20年ほどで、関係者全員がコミュニケーションを改善するのに十分なデザインパターンを実際に知っていた会話を10個ほど見たことはないと確信しています。

少し古風な言い方をすれば、設計パターンは特に失敗したために失敗しました。

パターンが多すぎる

2番目の主な要因は、どちらかといえば、最初はあまりにも多くのパターンに名前を付けたことだと思います。かなりの数の場合、パターン間の違いは十分に微妙であるため、特定のクラスが1つのパターンに適合しているか（またはおそらく両方に適合しているのか、おそらく両方に適合していないのか）を確実に判断することはほとんど不可能です。

意図は、より高いレベルでコードについて話すことができるようになることでした。特定のパターンの実装として、かなり大きなコードのチャンクにラベルを付けることができます。事前に定義された名前を使用するだけで、聞いているすべての人は、通常、そのコードを気にしているのと同じくらい知っているので、次のことに移ることができます。

現実はほぼ反対になる傾向があります。会議中に、この特定のクラスがファサードであることを伝えてみましょう。会議の半分の人は、それが何を意味するのか正確に忘れてしまったか、ずっと忘れていました。そのうちの1人は、ファサードとプロキシなどの正確な違いを思い出させるように頼みます。ああ、本当にパターンを知っている二人は会議の残りの時間を費やして、これが本当にファサードであるか「単なる」アダプターであるかを議論します（その人はまだ彼のプロキシのようだと主張しています）。

あなたの意図は本当に「このコードはあまりおもしろくありません。先に進みましょう」と言っているだけであるため、パターンの名前を使用しようとすると、気が散ることになります。

興味の欠如

ほとんどのデザインパターンは、コードの興味深い部分を実際に処理しません。それらは、「これらのオブジェクトをどのように作成しますか？」、「どのようにしてこのオブジェクトをそのオブジェクトと対話させるのですか？」などのことを扱います。これらのパターン名（および前述の詳細などの引数）を記憶することは、ほとんどのプログラマーがあまり気にしないものに多くのエネルギーを注いでいるだけです。

少し違って言えば、パターンは多くのプログラム間で同じことを処理しますが、プログラムを本当に面白くするのは、他のプログラムとの違いです。

概要

次の理由で設計パターンが失敗しました。

1. 彼らは臨界質量を達成できなかった。
2. パターン間の区別は、明瞭さを保証するのに不十分でした。
3. 彼らはほとんどの場合、コードの一部をほとんど扱っていましたが、とにかく誰も気にしませんでした。

パターンには抽象化が欠落しており、単純なパターンは抽象化されており、複雑なパターンは認識されないため、パターンは有用ではありません（いくつかの高レベルのものを除く）。

ポール・グラハムがそれを最もよく言ったと思う：

私のプログラムにパターンを見たとき、それはトラブルの兆候だと思います。プログラムの形状は、解決する必要がある問題のみを反映する必要があります。コード内の他の規則性は、少なくとも私にとっては、十分に強力ではない抽象化を使用していることを示しています。多くの場合、作成する必要のあるマクロの拡張を手作業で生成しています。

コード内のパターンを認識すると、何かが繰り返されることを意味するため、より優れた抽象化を使用する必要があります。より良い抽象化がない場合は、回避策としてパターンを使用します。新しいプログラミング言語はより優れた抽象化を提供するため、パターンの有用性ははるかに低くなります。
また、単純なパターンは簡単に抽象化されることが多く、複雑なパターンはめったに認識されません。
パターンが抽象化に置き換えられた場合、パターンの背後にある概念が消えることを意味するのではなく、概念は間接的ではなく明示的に記述でき、他のコードと比較して特別ではなくなり、次のように認識できなくなりますパターン。

ここで他の人が答えたことにはほぼ同意しますが、パターンの数が増えていない主な理由は、無数のパターンがある場合にパターンが意味を失うからだと個人的に思います。これらの少数のパターンの良いところは、それらが標準的な方法で多くの問題領域をカバーしていることです。無限のパターンドメインに焦点を当てると、パターンはまったくなくなります。「島の海岸線はどれくらいですか？」のようなものです。地図上で測定すると、まともな数字が付いてきます。しかし、より正確に取得してより高い解像度に到達しようとすると、長さがますます無限大に増加することがわかります（または不確実性;潮withや原子レベルで正確な境界をどのように測定しますか？）

他の回答のどれにも言及されていないことも関連しています：

動的に型付けされた言語の台頭。

この本が最初に出版されたとき、Javaは実際の作業をするには遅すぎるという深刻な議論がありました。現在、Javaはその速度のために、より表現力のある言語で頻繁に使用されています。たぶん、Ruby、Python、JavaScriptなどは、アプリケーションのいくつかの重要なクラスにとっては遅すぎるかもしれませんが、ほとんどの場合、大体の場合十分に高速です。そして、少なくともリリースごとに多くの機能が詰め込まれているにもかかわらず、少なくともJavaScriptは実際には高速になっています。

オリジナルのGoFブックには、smalltalkとc ++の両方のパターンがあり、メモリが役立つ場合、パターンは常にsmalltalkで短くなり、時には大幅に短くなりました。古典的なデザインパターンの機能のいくつかは、静的な型付けされたシステムに動的な機能を追加する方法です（既に説明したAbstractFactoryのように、実行時データに基づいて正しいクラスをインスタンス化します）。他の言語は、動的言語では非常に短いため、言語自体の慣用的な使用に単純に融合します。

それは起こりました。出版者と著者がさらに別の時流に飛び乗ろうとする（または作成しようとする）ため、コンピューターサイエンス全体をデザインパターンに還元する試みのように見えるもので、数百の書籍が出版されました。棚があります。最初にスキャンしてから相談したことはありませんでした。はい、実際の使用はほとんどまたはまったくなかったため、またはよく知られていなかったので、私は吸盤でした（たとえば、Type Objectは、 1段落ではなく12ページ）、そして明らかにパターンの数が少ない方が良いためです。実際、Type Objectの反論を投稿したとき、テキストをデザインパターンとして書き直すように指示されました。実話。これは、プロジェクトのもう1つの欠陥も示しています。レビューも除外も拒否メカニズムもありません。

実際のところ、GoFは「デザインパターンの徹底的な調査」を実際には試みませんでした。むしろ、彼らははるかに大きなプロジェクトに従事していました：CSに「パターン言語」を導入し、そのすべての奇妙な記法の力、参加者などは、基本的に誤解され、無意味であるため、単に失敗しました。

彼らが成し遂げたことは、2つのことでした。

• 訪問者パターンなど、いくつかの便利なトリックを公開する
• 工場、アダプター、イテレーターなど、ほとんど動かない名前の標準セットを提供します。すぐに設計されたCORBAを見ると、この値がわかります。インターセプターなどのあらゆる種類の「外国の」名前、サーバント、ブローカー、...

生じたもう1つの有用な概念は、「アンチパターン」、たとえば「ログとスロー」でした。このプロジェクトは、CSの多くの流行と同様に、独自の伝道と、さらに別のCS宗教として誤って採用されたことにより脱線し、そのような宗教のほとんどに道を譲りました： ）フレッドブルックス、1965）。本当に数年ごとにそれを再発見し続けなければならないことを悲しい。

PLoP（Pattern Languages of Program Design）というタイトルの書籍がいくつかありました。これらはそれぞれ、年次会議で発表された論文のアンソロジーです。

本を読んで、パターンのいくつかは興味深く、私にとっては新しいものであり、それらのいくつかは標準（「ハーフオブジェクトとプロトコル」など）であることがわかりました。

いいえ、GoFのコレクションは網羅的なものではなく、人々に新しいものを収集/説明/発見/発明するよう促しました。

「Wikipediaの記事にリストされている12の追加パターンのみ」も完全なコレクションではないと考えられます。

ギャングオブフォー（GoF）の本には、非関数型言語の経験豊富なプログラマーがツールベルトに持つほとんどのパターンが含まれています。これは、すべてのビルダーが使用方法を知っているツールの基本セットのようなものです。この本の主な貢献は、当時最も経験豊富なプログラマーが一般的に使用していたパターンに明確な名前を付け、設計オプションを議論するプログラマー間のコミュニケーションを支援することでした。

電気技師には通常のビルダーにはないツールがあることを期待します。同様に、WPFプログラマーが「依存関係プロパティ」の設計パターンを知っているか、「SQLプログラマー」がトリガーを使用する設計パターンを知っていることを期待します監査データを作成します。

ただし、これらは1つのテクノロジでのみ使用されるため、「デザインパターン」とは見なしません。

モデムデザインパターンブックには、「リファクタリング、既存のコードのデザインの改善（Martin Fowler）」および「Clean Code：A Handbook of Agile Software Craftsmanship（Robert C.Martin）」があります「あらかじめ用意された再利用可能なデザイン」としてではなく、現在のコードに追加しますが、それらは「デザインパターン」と同じです。

Erich Gammaのインタビューです。彼はパターンの選択と今日の変化を振り返ります（10年前の今日もそうです）。

http://www.informit.com/articles/article.aspx?p=1404056

ラリー：「デザインパターン」をどのようにリファクタリングしますか？

Erich： 2005年にこの演習を行いました。セッションのメモをいくつか紹介します。オブジェクト指向の設計原則とほとんどのパターンは、それ以来変わっていません。分類を変更し、新しいメンバーをいくつか追加し、パターンの一部を削除したかったのです。議論のほとんどは、分類の変更、特にどのパターンを削除するかについてでした。

どのパターンを落とすかを議論するとき、私たちはそれらをすべて愛していることがわかりました。（実際はそうではありません。私はシングルトンをドロップすることに賛成です。その使用はほとんど常にデザインの匂いです。）

そのため、変更点の一部を次に示します。

• 通訳者とフライウェイトは、「その他/化合物」と呼ばれる別のカテゴリに移動する必要があります。これらは実際には他のパターンとは異なる獣だからです。FactoryメソッドはFactoryに一般化されます。
• カテゴリは、コア、作成、周辺、およびその他です。ここでの目的は、重要なパターンを強調し、使用頻度の低いパターンと区別することです。
• 新しいメンバーは、Nullオブジェクト、タイプオブジェクト、依存性注入、および拡張オブジェクト/インターフェイスです（プログラムデザイン3のパターン言語、Addison-Wesley、1997の「拡張オブジェクト」を参照）。
• カテゴリは次のとおりです。
  • コア：コンポジット、ストラテジー、ステート、コマンド、イテレーター、プロキシ、テンプレートメソッド、ファサード
  • Creational：Factory、Prototype、Builder、Dependency Injection
  • 周辺機器：抽象ファクトリ、ビジター、デコレータ、メディエータ、タイプオブジェクト、ヌルオブジェクト、拡張オブジェクト
  • その他：フライ級、通訳

本の実際のパターンは時々非常に便利ですが、実際には本が提供するより強力なツールの単なるインスタンスです。 。

そのスキルを学ぶと、その目的に最適な方法で実装しているソリューションをいつでもカットできるため、すべてのパターンの正確な詳細を覚えておく必要がないことに気づきます。したがって、ますます多くのパターンを書き留めるという考えは、非常に学術的で無意味に思えます。

そのため、既知の文書化された設計パターンの数が大幅に増加すると予想しました。

それは起こりませんでした。GoFの本が出版されてから20年以上経っても、Wikipediaの記事には12個の追加パターンしかリストされていません。（特定のトピックを扱っているため、ここでは同時実行パターンを含めませんでした。）

GoF本とWikipediaは、既知のデザインパターンの唯一のソースではありません。Amazon.comで「デザインパターン」を検索するだけで、数百冊の本を入手できます（この検索を試してください）。ウィキペディアの記事で最もよく知られているパターンのみをリストしていると思います。

したがって、問題は、文書化された設計パターンが十分にないことではありません。むしろ、誰もがそれらをすべて覚えることができないほど多くあり、ほとんどのプログラマーはごくわずかしか認識していません。共通パターン言語の大きな約束は、この時点で破綻します。

まだ考えられていない構造がおそらくたくさんあります。人々がソフトウェアを開発している限り、克服すべき設計上の課題があります。それらのいくつかは、他の人が利用できる巧妙な新しいパターンを使用して解決される可能性があります。

プログラミング言語は、最も一般的に使用されるパターンを抽象化するために開発および進歩しました。これらのパターンはまだ言語の設計に存在しています。したがって、それらは今日無視されるかもしれませんが、それはそれらを重要ではありません。

家を建てる方法の知識は、私たちのためにそれを行うことができるロボットを手に入れたら、突然重要ではなくなりますか？私はそうではないと主張しますが、そうではありません。需要は急激に低下し、他の誰も勉強していないので、それは関連性が低く、確かです-そしておそらく勉強する価値がはるかに少ないです。

いいえ、パターンスペースが使い果たされたとは考えていません。別の答えが指摘したように、それは無限になりそうです。しかし、システム設計の需要が減少するにつれて、抽象化の塔の高さとプログラミング言語の能力を高めると、最上層に構築する人が少なくなり、塔の構築方法の詳細に注意を払うようになります。

パターンは無限です。各パターンを微調整したり、n個のマッチを組み合わせて新しいパターンを作成したりできます。エンタープライズ統合パターンも明確に定義されています。ドメインごとにパターンが進化し、Pythonやscalaなどの表現力豊かな言語にも変化します。