私は現在、デザインパターン試験（明日行われます...）の勉強をしています。「テスト試験」の1つで、次の質問が見つかりました。
ジム・コリアンは招待講演の中で、GoFの本にはデザインパターンが1つもないと述べました。これについてどう思いますか？
私はこの特定の講義に参加していなかったので（前学期でした;）、彼が何を意味していたのかわかりません。ジム・コリアンがそれを言ったという証拠はありませんが、それは問題ではないと思います。
彼はこの声明で何を意味したと思いますか？
（質問がこのフォーラムに適切かどうかはわかりませんが、質問したいと思います。）
GoFは、より広いデザイン分野でこの用語を普及させたクリストファー・アレクサンダー（本の前書きで述べているように）からそのパターンのインスピレーションを得ていると主張しています。アレクサンダーにとってパターン：常にパターン言語の要素です。人間の深い感情に貢献します。本質的に常に幾何学的です。少なくともいくつかのGoFパターンは、これらのポイントの少なくとも1つで失敗し、いくつかは3つすべてで失敗します。「パターン」は中立的な英語の単語ですが、GoFの文化的および歴史的なルーツは、アレクサンドリアのインスピレーションの呼び出しと組み合わされて、その祖先の基本的な基準による判断の対象となり、欠けています。彼らは、アレクサンダーとは異なることを知っており、知っていることを表明していますが、それでも、彼が作成、調査、普及した用語を使用することを選択しています。そして私は彼らにその責任を負わせます。（とはいえ、彼らはすべて大切な知人です。私は数年前に失ったジョン・ブリシディーズの近くにいて、この背後にあるより深い問題についてリチャード・ヘルムとエリック・ガンマと素晴らしい対話をしました。ラルフとの私の議論はそれほど面白くありませんでした。エンジニアリングレベルで停止します。）
言葉は物事を意味します。「パターン」という用語のアレクサンドリアの意味は、本を書いたときにGoF（またはソフトウェアコミュニティ全体）によって十分に理解されていませんでしたが、3つの情報源に基づいた当時の下品な認識に基づいていました。 1.エーリヒガンマの博士論文; 2. Ralph Johnsonのフレームワーク作業、および3. C ++イディオムの本（これは、セクション6.3のGoF本自身のソースの説明にあります）。（ああ、クヌースも影響を受けました。）私はそれについて著者に挑戦し続けましたが、人々はそれを好きで、人々はそれを好きだったので、勢いは続きました。
数年後（2004年12月2日）、GoFの1人が、アレクサンダーが伝えようとしていることを最終的に理解したという彼の「あは」の経験を説明するために私に手紙を書きました。これは、GoFの本の内容の根底にあるものとはかなり異なっていました。
最後に、長い曲がりくねったルートを介して、「生成パターン」と断片的な成長を実現しました。主に、ソフトウェアのいくつかの興味深い普遍的なプロパティ（スケールフリーで小さな世界）を介して
少し遅い私は時々...しかし最終的にそこに着きました...
残念ながら、人々が彼らのように彼らを有用だと思うのは、現代のプログラミング言語の告発です。言語には、アレクサンダーがパターンの特徴であると考えている壊れた対称性を表現するための適切な構成がなく、複雑な設計に固有のものです（Nature of Order、p。187： " ...一般に、単純化された新古典主義者のタイプが物事の生活に貢献することはめったにありません。なぜなら、世界中の複雑な場所では、ほとんどの場合、対称性を破る必要のある、場所、コンテキスト、機能の問題など、複雑で非対称な力が働いているからです。 ; op cit。、pp。63-4： "自然もまた、構造を保存する変換を繰り返し適用することによって支配される美しい構造を作成します。これに関連して、私が構造保存変換と呼んでいるものは、物理学で「対称性の破れ」として知られるようになったものと非常に密接に関連していることに注意することは有用だと思います。"）。Javaはこれについて特に悪いですが、その祖先であるSmalltalkもそうです。C++は局所的な対称性の破れを説明する機能が豊富ですが、ほとんどの人はそれらの使い方を本当に知りません。 、そしてCLOSやSchemeのような言語を持っている人は、適切に設計された言語（CLOSやSchemeなど）はGoFパターンを必要としないため、GoFパターンを理解していないと言います。私は主に同じ陣営にいます。
この背後には、デザイン運動（Thackara（ "Design after Modernism"、1989）、Naur、Alexander、Cross（ "Developments in Design Methodology" 1984）、および1980年代の他の著者）にまで遡る多くのデザイン理論があります。現時点でのデザインムーブメントの作業の明らかな発見に照らして、プログラマーがこの一連の文献を知っていることや、CSの考え方がいかに間違っているかを常に驚かせてきました。1993年にパターン分野（ヒルサイドグループの元の7つ）を創設した私たちの人々は、この文学の主要なテーマに精通していました。PLoP会議は、これらの基盤から根本的に発展した一連の文献を発展させ、アレクサンダーが求めていた「名前のない品質」よりも不可解な知識に焦点を当てました。
私がC++プログラマーにイディオムを導入した理由は、言語が邪魔になったときにオブジェクト指向プログラミングを実行できるようにするためでした。現在、イディオムの必要性を大幅に減らすDCIのようなより強力なアプローチがあります。パターンは引き続きドメインレベルで適用されます—これはAlexanderのビジョンに沿ったものです。いくつかの優れたパターン言語が書かれています。例：Hanmer（Patterns for Fault-Tolerant Software、2007）; Elorantaらによる。（分散制御システムの設計、2014年）、およびアレクサンダー自身が指摘した組織パターンは、必要な基準を満たしていました（Coplien and Harrison、2004年）。
アレクサンダーと私（そしてリチャードガブリエル—彼の「ソフトウェアのパターン」を読んだ—そして他の人たちも）は、GoFによって再定義される前に設計で十分に確立されていた用語のこの初期のリダイレクトに失望を共有します。はい、彼らはそれらをデザインパターンと呼んでいるので、それらはデザインパターンです—ギャングオブフォーによるデザインパターンの本についての議論の文脈では。設計理論とアーキテクチャのより広いスキームでは、それらはそうではありません：それらは単なるイディオムです。著者自身が言うように、それが彼らが始めた方法です。
アレクサンダーのビジョンをソフトウェアコミュニティに戻すために、いくつかの取り組みが進行中です。ScrumPLoP®コミュニティ（http://scrumplop.org）は、パターンのすべてのアレクサンドリアの根拠を非常に真剣に受け止めています。昔のアレクサンドリア人の同僚で、CESのIT業務を行っていたグレッグ・ブライアントが私に連絡を取り、アレクサンダーのビジョンをソフトウェアに戻すための彼の仕事について話してくれました。ディック・ガブリエルと私はしばらくおしゃべりをしていませんが、ディック・ガブリエルも常に何かを念頭に置いていると確信しています。その間、私はアレクサンダーの同僚である中野宏と直接仕事を続けています。彼はアレクサンダーのアイデアを結び付けています（彼はタイムレスのタオテチンの観点から直接表現しました））日本文化の類似点に直接。西洋文化に靴べらを入れようとするよりもはるかに適しています。それはおそらく私の主張を理解することができることへの欲求不満のいくつかを説明しています—それは知識ビジネスで働く専門家の言い訳ではありませんが。
もちろん、この根拠はすべて、公表された弁証法と研究の問題であり、時間をかけて研究することをいとわない人なら誰でも利用できます。ここにあったようにすぐに却下できるほどカジュアルな問題ではありません。20年かかりました—そして私は情報源に直接アクセスできました。平均的なプログラマーがこれらのことを掘り下げるのは難しいことは理解できますが、宿題をする前に、よく研究されたポジションを手に負えないように却下する前に、もう少し研究を行うことをお勧めします。それはStackOverflowのものです。
GoF独自の定義によれば、それはデザインパターンでいっぱいです。したがって、推論により、Coplienはデザインパターンの異なる定義を持っているか、CoplienはGoFの定義を誤解しているか、誤解している、またはGoFの定義がGoFパターンと一致しないと主張しています。
この質問では、2つの定義の違いを説明し、どちらの定義を好むかについて意見を述べてください。おそらくあなたの意見は、学界のようにあなたの意見の理由（方法論）は意見自体よりもはるかに重要です。