翻訳: デザインパターン・メーリングリスト有志
原文は Doug Lea<dl@cs.oswego.edu> によってメンテナンスされています。
原文の最終更新は2000年11月です。
この文書は通常の意味でのFAQではありません。 この文書には、 patterns-discussionメーリングリストで議論されてきたトピックの 非常に短いサマリーがQ&Aの形式で含まれています。 項目の取捨選択および内容には管理者の主観的な判断が入っています。 このFAQは不定期に更新されます。
パターンに関する情報は、 The Patterns Home Pageを参照してください。 そこにはオンライン上のパターンへのリンク、 パターンに関する論文、パターンを扱った書籍の説明、 カンファレンスの一覧、 そしてパターンに関連したメーリングリストが含まれています。
多くの技術用語によい定義がないのはなぜでしょうか？ 「パターン」という用語は、 例えば「オブジェクト」 と同じくらいの地歩は少なくとも築いていると思います。 「あるコンテキストにおける問題に対する1つの解法」 という短いスローガンを気にかける人は誰もいないようです。 しかし、このスローガンはあまりにも短いので、混乱を招く可能性があります。 このスローガンに登場する用語を次のように展開するといいかもしれません。
定義に関するもっと広い議論は、 Patterns Home Pageと WikiWikiWebにあります。
あなたの好きなように呼んでかまいませんよ。 でも、他の多くの人たちの呼び方を変えるにはもう遅すぎるでしょうね。
パターンという言葉の表す概念はとても広いので、 どんな種類のコンテキストにも適用可能です。
「ギャング・オブ・フォー」(四人組:GoF —— Gamma、Helm、JohnsonとVlissides)の 『デザインパターン』という本は、そのほとんどの記述を 「マイクロアーキテクチャ(「オブジェクト構造」とも言います)」 を扱ったパターンに費しています。 マイクロアーキテクチャというのは、 オブジェクト指向開発を行う場合によく見られる、 オブジェクト(や それらのクラス)の間の静的あるいは動的な関係のことです。 「デザインパターン」という用語はこのような種類のパターンを示すために 使われるようになっています。 この文献に記述されたパターンは、 もっとも一般的な種類のパターンとなっています。
どう考えてもパターンとは言えない場合でも、 オブジェクト構造ならみな「デザインパターン」という用語を使う人がいますが、 これは誤りです。やめてください。
ソフトウェア関連の既存の例としては、次のものがあります。
while (*dst++ = *src++);
さらにパターンは、ソフトウェア開発以外のいくつかの分野にも適用されています。
パターンは主にそのうちの何か1つに関連しているものではありますが、 そのひとつだけではパターンとは言えません。 パターンとは、 それらを実際の開発現場に適用する方法と理由を示すガイダンス を提供するものです。
パターンは実装ではありません。 実装や他の技術的な製品を生み出す際の「いつ、なぜ、どうやって」を示すものです。
実装(クラス、フレームワーク、ツールなど)を使った記述が適した解法もあります（多くはないです）。 その場合、実装を通して、 知るべきことや行うべきことが開発者に全部伝わってしまう、 ということになります。 たとえそうだとしても、コード自身はパターンではありません。
パターンに書かれる解法は、ハウツーガイドや料理のレシピなどと似て、 段階を追った一連の工程で表現されることがあります。 しかし、繰り返しますが、このような工程はパターンのひとつの側面だけを形作るものです。 パターンはまた、ハウツーガイドに見られるものよりも、 コンテキストに関してはより広い適用範囲と一般性を持ち、 フォースの同定と解決に関してはより信頼性の高いものとなることを目指しています。
いくらか重なりあう部分があるようです。
パターン情報センターのような機関はありません。 でも、パターンの情報を探すことはそれほど難しくはありません。 いくつかのスタート地点を挙げてみましょう。
Alexanderは、パターンを考案した（ソフトウェアではなく建築物の）建築家です。 短い経歴と、関連した読み物やWebページへのリンクは、 Salingaros's Notes on Christopher Alexanderにあります。
自分で選んでください。 Alexanderのパターンのほとんどすべては、 次のような形式で記述されています。
[もしも] ある[コンテキスト]で
ある[例]のような
[問題]が
[フォース]を伴って現れた
[ならば] いくつかの[理由]で
[デザインのフォームやルール]を適用して
[解法]を組み立て、
さらに[新たなコンテキスト]や[別のパターン]へ導く
様式上、多くのバリエーションがあります。 パターンについて書いている既存の本で、 完全に同じフォーマットを使用しているものは2つとありません。 フォーマットの中には、 純粋に物語のような形式になっている Portland Formもあります。 おそらく最も一般的なフォーマット（ デザインパターン本で使われている）は、これの逆で、 デザインのフォームやルールの記述から始まって、 問題や、コンテキストや、そのパターンを適用できる例題がその後に記述されています。
パターンの構造と内容を記述する際には、 形式の違いによらず以下の要素が必要になります。
〔訳注： パターン記述の例は、 デザインパターンのテンプレートを参考に〕
ソフトウェアエンジニアが設計や実装の正当性を示すときに使っている判断基準の類いを、 フォースという概念は一般化します。 例えば、コンピュータサイエンスにおけるアルゴリズムの古典的な研究において、 解決すべき主要なフォースは「効率」（時間的な複雑さ）です。 しかしながら、パターンというものは、 これまで生み出してきたあらゆる作品の開発においてあなたが遭遇したような、 さらに広範囲で、さらに計測が困難で、互いに矛盾した目的と制約を取り扱います。 例を以下に示します。
〔訳注： 型の安全性については例えば、 ParcPlace Type-Safety Discussionを参照してください。
生存性(liveness)とは、 例えば「スレッドがデッドロックに陥ったり、 入りたいクリティカルセクションにいつまでも入れなかったりすることのない」 性質のようです。
トランザクション性(transactionality)とは、 「一連の処理がすべて 完全に実行されるか、すべて取り消されるかの どちらかという性質」のようです。 解説1 、 解説2 、 解説3、なども参考に。
フォールトトレランス(耐障害性) Fault Toleranceの解説はこちらです。 〕
Tres Seaverは、こう付け加えています。 「〔フォースの〕利用は、ソフトウェアよりもずっと古くからある。 建築学や、機械工学・土木工学においても、 設計された要素(entity)は物理的なフォース(力)が相互に作用するシステムとの関係の中に存在していた。 それぞれのフォースを解決しない設計およびそのようなシステムは、 ことごとく失敗する（例えば、Tacoma Narrowsの吊り橋は、 風に対する動的な荷重の変化を解決するのに失敗した。 Texas A&Mにおける焚き火は、作業者たちの動きから生じる荷重に耐えられずに失敗した）。 拡大解釈するなら、 複雑に、時には予見不可能なまでに相互作用する他の要求を、 設計というものは満たさなければならないのだ。 「フォース(力)」という用語は、 こういった状況も表現できるように拡張されたのである」
〔訳注： Tacoma Narrowsの吊り橋は、 1940年に完成後、わずか4ヵ月で、 秒速19メートルの横風で崩壊しました。 『失敗学』(畑村洋太郎)p.28参照とのこと。 『失敗学のすすめ』（畑村洋太郎 著；講談社）『だれがタコマを墜としたか』（川田忠樹 著；建設図書）
Texas A&Mにおける焚き火とは、 Texas A&M大学のフットボール大会の、前夜祭用大焚き火の薪が崩れて18人が死んだ事件のようです。 http://bonfire.tamu.edu/〕
Alexanderのパターン記述は、 パターンはフォース同士の一種の「均衡」を表現しなければならない、 という考えを含んでいます (Alexander自身ですら、 いつもこのことを納得できるやり方で実行しているわけではない、 と批判されてきました(Alexanderは自分でもそう批判しています))。 均衡というのは、 例えばコンピュータサイエンスのアルゴリズムの解析に見られるような、 最適性と同じ概念です。 しかし、均衡は、1つ前のFAQに書かれている、 計測困難なフォースというものに対して適用されるものです。
ある解法がフォースを最適に解決するということを分析的に「証明する」ことは たいていは不可能です （実際問題、ここで「証明」の概念を定義することは困難です。 またその証明にどんな利用法があるのか見ることすら困難です）。 その一方で、 解法について誤った・怪しげな正当化を行うような 「とにかくこうなんだ」というストーリーを思いつくのはとても簡単です。 最高に良心的なパターン作者であっても、 ある解法がどうしてそれほど有効に機能するのかを 完全に理解しているわけではありませんし、 応用の可能性を完全に理解しているわけではありません。 かつてRalph Johnsonは次のような投稿をしました。
あるパターンが解く問題をはっきり理解するのは、困難なことが多いです。 しょっちゅう目にするので「これはパターンだ」ということはわかります。 それから、そのパターンを導入して外界がよりよくなれば、 「これはよいパターンだ」ということもわかります。 しかし、外界の方を見た場合、 どうして物事がそのようになっているのかを理解するのは難しいものです。 あるパターンが解く問題をはっきり理解する方法というのは、 事物を設計するときに自分自身を見ることだ、と私は思います。 あるパターンを私たちが使うのに、 どんな条件がきっかけとなるのでしょうか。
パターンが解く問題についてAlexanderが記述しないことがあるのはなぜかというと、 実は彼自身も知らない場合があるからなのだ、と思います。 GoFの本が問題についてあまりよく書いていない理由も、 これと同じに違いありません。 〔パターン記述の〕フォーマットのせいで著者が問題を無視してしまった、 ということではありません。 問題に対する著者の理解の結果が、 彼らの採用しているフォーマットとなったということなのです。
こういった理由から、パターンのコミュニティは、 議論が以下のようなものでバックアップされて いることを期待しています。
パターンであるという証拠が提供されるまで、 パターンはプロト・パターン(proto-pattern) と呼ばれることもあります —— パターン候補ということです。
一言ではうまく答えられません。 The Timeless way of building(Alexander著、ISBN 0-19-501-919-9) を読まなくてはならないでしょう。 〔訳注： 『時を超えた建設の道』（鹿島出版会）平田翰那訳、ISBN4306043061〕
「AlexanderはQWANについて、一言も書かなかったんだぜ」と、 たいそうオタクなパターン狂たちはうそぶきます。 「QWANは、言及するのをはばかりたくなるような、 神秘的で・奇妙に聞こえ・形而上学的なゴタクなら 何でもパターンを結びつけてしまう」と、 たいそうオッチョコチョイのパターン狂たちはうそぶきます。
〔訳注： 『生成的開発プロセス・パターンランゲージ』(James O. Coplien)の中の「無名の品質」の部分が参考になるかもしれません。 〕
たぶん、理想的には、そういうことはありえません —— 良いパターンの集合があれば、 あなたが直面するであろう無数の悪いデザイン （アンチパターンといわれることがある） を避けることができるでしょうし、 さらに、与えられたパターンを適用するのに不適切なコンテキストも すべて避けることができるでしょう。 しかし、非常に悪いのに 広まり過ぎているアイディアについては、 はっきりと言及しておく価値があります。 そうするための一つの方法は、 パターンの記述に「よくある罠と落とし穴」というセクションを含めることです。 悪い解法（不適格な方法）の記述は、 良い解法への動機付け、論理的根拠付け、フォースの一部になり得ます。 パターンは、悪い解法を良いものに変える方法を述べる場合もあるでしょう （「修正前／修正後」や「修理」というセクションなどで）。
たぶん、理想的にはそうはできません —— それぞれの解法は、 その解法を最もよく適用できるコンテキストに束縛されていなければならないのです。 しかし、常にそのようにするのは難しすぎます。 他の解法については、 述べないよりも、述べた方がいいでしょう。 なぜなら、 他の解法との違いの原因となっているフォースを発見することで、 さらなる改善を行う足場を築くことになるからです。 たとえ、他の解法が本質的には違っているとしても、 ほとんどのコンテキストとフォースを共有する一群のパターンを、 1つのプレゼンテーションの中にグルーピングすべきか、 というパターン記述の様式上の問題は残ります。
パターンの中には、 あなたのおばあちゃんですら知っているくらい とても良くて役に立つものがあるからです。 パターンを書くことによって、 そのアドバイスのコンテキスト、価値(value)、そしてその意味(implications)が おばあちゃんのアドバイスよりも明確になるのです。
もちろん、そんなことはありません。
通常の意味でいう、定式化された基礎はありません。 パターンは、あらゆる種類の理論的・経験的な土壌から 発生したデザインの概念を表現することができます。 その一方で、パターン指向の設計の概念の多くは、 工学の広範な分野における「設計理論」についての古典的な研究から、 およびそれほど古典的ではない研究から発生しています（ the Patterns Home Pageの参考文献にリストアップされている論文を参照してください）。
自由に試してください。 しかし、もしも、 コンテキストの記述、 解決する問題、 解法の妥当性を示す証拠、 構築や実装のためのガイドライン、 あるいは、他のパターンとの関連を書き落としていたら、 その「形式的な表記法によるデザインの表現やデザインルール」は「パターン」 にはならないということは心に留めておいてください。
よくできたコードは再利用すべき、というのと同じような理由です。 すなわち、他の人の知識や経験から恩恵を受けようということです。 その人は、コンテキスト、フォース、そして解法を理解するために、 あなたがこれまで、あるいはこれから行う努力よりも 大きな努力をしてきたのです。 さらに、パターンはコードよりももっと再利用がしやすいのです。 というのは、パターンを適用することで、 既存のコンポーネントが再利用できないような特殊な状況を扱う ソフトウェアを作ることができるのです。
さらに、パターンを使うと、 開発者たちは 共通の開発上の問題を取り扱う、 共通の名前と概念の集合を得ることができます。 要するに、コミュニケーションが強化されることになるのです。
いいかもしれません。 でも、パターンは人と人とのコミュニケーションのためのものです。 もしもそのツールが、他の人たちとのコミュニケーションを促進するならば、 それはよいものです。 でもそのツールが、 パターンがねらいとしていることを、 コンピュータで実行可能にするというだけなら、 それはよいものとはいえません。
パターン・ランゲージは、相互に関連したパターンの集合です。 個々のパターンはみな同じコンテキストの一部を共有し、 いくつかのカテゴリーに分類されているかもしれません。
この用語はAlexanderに拠ります。 Alexanderの「ランゲージ」という用語の使い方は一般的ではありませんが、 誤りというわけでもありません。 もしパターンの集合を見て、非常に形式的にとらえなおすなら、 個々のパターンは「生成規則」だといえます。 もし、あなたがオートマトン理論を覚えているならば、 生成規則のセットが帰納的可算言語を特徴付けるひとつの手段であることを思い出すでしょう。 〔オートマトン理論で「生成規則」の集合が「言語」を定めるように、 「パターン」の集合が「パターン・ランゲージ」を定めることになるのです〕。
なぜなら、あなたがそれを書いていないからです。 興味を持っているなら、あなたは何かを知る可能性が高くなります。 そして何かを知ったなら、あなたはパターンを書くことができるのです。
以下のことをお勧めします。
Ward Cunninghamの、 Tips for Writing Pattern Languages (パターン・ランゲージを書くコツ)もご覧ください。
それをパターンとして 書いてみてください。
誰もが知っていなくてはならないパターンのうち、 まだ発見されていないものはほとんどない、と考えている人もいれば、 各分野に固有の文書化すべきパターンは もっとずっと多いと考えている人もいます。 おそらくどちらも正しいのでしょう。 パターンを書いてみてください。 そうすれば、新しいパターンを発見できるでしょう。
なるかもしれません。
おそらく利用できるでしょう。 けれども、パターンを利用した場合、 その表記法の範囲を越え、 その手法にほとんど従わないことになるかもしれません。
あなたが、とてもラッキーで、 直面している問題に対する完全なパターンのセットがすでにあって、 その問題に対しては次から次へと流れるようにパターンを応用することができ、 一度も後戻りせずに最終製品までたどり着く、 なんてことも原理的にはありえるでしょう。 でも、実際にはそんなにラッキーなことは決してありません。
おそらくあるでしょう。 しかし、この件についてたくさん議論しても、 パターンを活用した開発プロセスが何であるかは分からないでしょう。 まずは、実際にパターンを使ってみてください。 そうすれば、パターンを活用した開発プロセスが見つかります。
31の回答と同じ答えです （まずは、実際にパターンを使ってみてください。 そうすれば、効果があるかどうかが分かるでしょう）。
その両方が必要です。 どちらか一方がより必要性が高いということはありません。
一般に、次のことがお勧めできます。
理由は一つだけではないようです。 人々は次のような要因を挙げています。 永いあいだに培われたプラクティスと建築家のプロフェショナルとしての文化との軋轢（あつれき）、 経済的な要因、 Alexanderが、人々に自分の独自の家を設計し建築させることに焦点を当てているという事実、 そして『パターン・ランゲージ』に書かれている特定のパターンが、 どれだけ良くどれだけ役に立つのか意見が分かれている点、 などです。
実際にそうしているという報告があります。
もちろんそうです。これは避けられません。
もっと具体的な質問にしてください。
原文はDoug Leaが書き、パブリックドメインとして公開されています。
Last modified: Tue Nov 7 07:27:54 EST 2000
この翻訳は、 デザインパターン・メーリングリストの有志によって行われ、 結城浩がまとめました。 訳注は、有志からの情報を元に整理しました。 誤訳・改善案がありましたら、 デザインパターン・メーリングリストへご連絡ください。 翻訳に参加、意見投稿をしてくださった方のお名前を以下に列挙します（順不同、万一抜けがあったらご連絡ください）。 瀬戸さん、ヤスさん、中村さん、柴山さん、清水さん、上手さん、 さくさん、 Ｋ仲川さん、井芹さん、あまぴょんさん、 曾根さん、岡田さん、海内さん、重信さん、小竹さん、谷内上さん、 小山さん、みかままさん、沼田さん、永野さん。
この翻訳はパブリックドメインです。
訳語は以下のように統一しています。
Patterns-Discussion FAQ (原文)
http://gee.cs.oswego.edu/dl/pd-FAQ/pd-FAQ.html
デザインパターンFAQ (訳文)
https://www.hyuki.com/dp/dpfaq.html
デザインパターン・メーリングリスト
https://www.hyuki.com/dp/dpml.html