ホーム > デザインパターン・メーリングリスト > デザインパターンFAQ

翻訳: デザインパターン・メーリングリスト有志

原文は Doug Lea<dl@cs.oswego.edu> によってメンテナンスされています。

原文の最終更新は2000年11月です。

この文書は通常の意味でのFAQではありません。 この文書には、 patterns-discussionメーリングリストで議論されてきたトピックの 非常に短いサマリーがQ&Aの形式で含まれています。 項目の取捨選択および内容には管理者の主観的な判断が入っています。 このFAQは不定期に更新されます。

パターンに関する情報は、 The Patterns Home Pageを参照してください。 そこにはオンライン上のパターンへのリンク、 パターンに関する論文、パターンを扱った書籍の説明、 カンファレンスの一覧、 そしてパターンに関連したメーリングリストが含まれています。

「パターン」という用語によい定義がないのはなぜでしょうか？ 多くの技術用語によい定義がないのはなぜでしょうか？ 「パターン」という用語は、 例えば「オブジェクト」 と同じくらいの地歩は少なくとも築いていると思います。 「あるコンテキストにおける問題に対する1つの解法」 という短いスローガンを気にかける人は誰もいないようです。 しかし、このスローガンはあまりにも短いので、混乱を招く可能性があります。 このスローガンに登場する用語を次のように展開するといいかもしれません。 コンテキストとは、 繰り返し発生する一群の状況のことを指します。 その状況にパターンを適用することになります。

問題とは、 コンテキストで起きる一群のフォース ――目的と制約――のことを指します。

解法とは、 これらのフォースを解決するために適用できる 正規化された設計の形、あるいは設計のルールのことを指します。 定義に関するもっと広い議論は、 Patterns Home Pageと WikiWikiWebにあります。

こうしたものを記述するのに、「パターン」よりもいい言葉は使えないんですか？ あなたの好きなように呼んでかまいませんよ。 でも、他の多くの人たちの呼び方を変えるにはもう遅すぎるでしょうね。

パターンは他のどんなものに適用できますか？ ソフトウェア関連の既存の例としては、次のものがあります。 プログラミングのイディオム 例えば、C++での入れ子になったクラス、 Javaでのインターフェース、 Smalltalkでのカスケード呼出し(メッセージの流し込み)の特定の利用法です。 コーディングのイディオム 例えば、次のようなCのイディオムです。 while (*dst++ = *src++); データ構造 例えば、木構造やバッファなどです。 アルゴリズム 例えば、並列処理のためのアルゴリズムなどです。 プロトコル 例えば、並列オブジェクトシステムなどで使われるプロトコルなどです。 新しいフレームワーク開発 例えば、ユーザインタフェース(UI)ツールキットのためのものです。 既存のフレームワークの利用 例えば、OpenDoc, JavaBeans, …。 分析モデル 例えば、課金ルールをどう取り扱うかといったことです。 システムアーキテクチャ 例えば、BlackboardやBrokerといったアーキテクチャです。 〔訳注：参考 http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/〕 開発組織 例えば、開発チームの構造や力学といったものです。 開発プロセス 例えば、オブジェクト指向分析設計における工程や戦略といったものです。 さらにパターンは、ソフトウェア開発以外のいくつかの分野にも適用されています。

パターンとコーディングのイディオムとの違いは何ですか？ デザインとの違いは？ OMTやUMLダイアグラムとの違いは？ ユースケースとの違いは？ プロトコルとの違いは？ アルゴリズムとの違いは？ ヒューリスティック(発見的手法)との違いは？ アーキテクチャとの違いは？ コーディング標準との違いは？ コーディングスタイルとの違いは？ 開発手法との違いは？ パターンは主にそのうちの何か1つに関連しているものではありますが、 そのひとつだけではパターンとは言えません。 パターンとは、 それらを実際の開発現場に適用する方法と理由を示すガイダンス を提供するものです。

パターンとクラスの違いは何ですか？ 再利用可能なコンポーネントとの違いは？ パラメータつきの(テンプレート)クラスとの違いは？ クラスライブラリやパッケージとの違いは？ フレームワークとの違いは？ ツールとの違いは？ コード生成器との違いは？ パターンは実装ではありません。 実装や他の技術的な製品を生み出す際の「いつ、なぜ、どうやって」を示すものです。 実装(クラス、フレームワーク、ツールなど)を使った記述が適した解法もあります（多くはないです）。 その場合、実装を通して、 知るべきことや行うべきことが開発者に全部伝わってしまう、 ということになります。 たとえそうだとしても、コード自身はパターンではありません。

パターンとハウツーガイドとの違いは何ですか？ パターンに書かれる解法は、ハウツーガイドや料理のレシピなどと似て、 段階を追った一連の工程で表現されることがあります。 しかし、繰り返しますが、このような工程はパターンのひとつの側面だけを形作るものです。 パターンはまた、ハウツーガイドに見られるものよりも、 コンテキストに関してはより広い適用範囲と一般性を持ち、 フォースの同定と解決に関してはより信頼性の高いものとなることを目指しています。

パターンの研究と、 ドメイン固有のソフトウェアアーキテクチャ・ ソフトウェアの再利用・ ソフトウェアエンジニアリング・ その他の分野の研究とはどんな関連がありますか？ いくらか重なりあう部分があるようです。

パターンを記述するのに最適なフォーマットは何ですか？ 自分で選んでください。 Alexanderのパターンのほとんどすべては、 次のような形式で記述されています。 [もしも] ある[コンテキスト]で ある[例]のような [問題]が [フォース]を伴って現れた [ならば] いくつかの[理由]で [デザインのフォームやルール]を適用して [解法]を組み立て、 さらに[新たなコンテキスト]や[別のパターン]へ導く 様式上、多くのバリエーションがあります。 パターンについて書いている既存の本で、 完全に同じフォーマットを使用しているものは2つとありません。 フォーマットの中には、 純粋に物語のような形式になっている Portland Formもあります。 おそらく最も一般的なフォーマット（ デザインパターン本で使われている）は、これの逆で、 デザインのフォームやルールの記述から始まって、 問題や、コンテキストや、そのパターンを適用できる例題がその後に記述されています。 パターンの構造と内容を記述する際には、 形式の違いによらず以下の要素が必要になります。 最良のプラクティスの記述 あるいは、少なくとも一般に受け入れられているプラクティスの記述が必要です。 ある人たちは、パターンを、決定的なソフトウェア・エンジニアリングのハンドブックの作成に向けたステップだと見ています。 適切な一般性 そのパターンが繰り返して起こるという証拠が必要です。 たいていの場合、 よく知られている用例を何個か要約することが必要となります。 また、そのパターンを適用できない状況について言及することも必要かもしれません。 その場合には、替わりのパターンへのリファレンスも含める必要があるでしょう。 スコープ 誰かがそのパターンを適用したいと思うコンテキストを、詳しく記述します。 また、そのパターンが結果として別のパターンの応用例となることが多いなら、 そちらのパターンへのリファレンスも含めます。 建設性 パターンというものは、 人々がその解法の実例を1つ作り上げるような形で表現されます。 本質がどこにあるかを示す関係図が必要になるかもしれません。 また、パターンの利用者が従わなければならない一連の設計工程が必要となるかもしれません。 その場合には、解法のフォームの記述や例示も必要となるでしょう。 完全性 関連するすべてのフォースが記述されているということです。 有用性 その解法がうまくフォースを解決できるという証拠です。 もしフォースの一部分しか解決できない場合や、 その解法が新たなフォースを生み出す場合には、 適用できる関連パターンへのリファレンスが必要です。 実例 解法のステップを示した実例と、 既存のソフトウェアの文書化された使用法の両方です。 適切なレベルの抽象化 例えば、 「他のレベルの間接的な手法を加えながら」 というのは発見を促すのに有用な表現ですが、 一般的過ぎるし、複数の側面を持ち過ぎているので、 よいパターンとはいえません。 オリジナリティの欠如 新たな解法は、パターンではありません （しかし、要約・統合・焼き直しをしてパターンとしての記述を導くことは 目新しいものかも知れません。 また、パターンは新たな用途を導き出すかも知れません）。 適切な名前 共有されるボキャブラリを開発者に提供する、 簡潔で対象をよく言い表わした名前です。 明確さ 人々は、 そのパターンを適用するどうか、 また適用するならどのように適用するかを、 パターンの表現方法とスタイルによって簡単に判断することができ、 パターンを自分で「再発明」する必要がありません。 〔訳注： パターン記述の例は、 デザインパターンのテンプレートを参考に〕

「フォースの解決」とは何ですか？ Alexanderのパターン記述は、 パターンはフォース同士の一種の「均衡」を表現しなければならない、 という考えを含んでいます (Alexander自身ですら、 いつもこのことを納得できるやり方で実行しているわけではない、 と批判されてきました(Alexanderは自分でもそう批判しています))。 均衡というのは、 例えばコンピュータサイエンスのアルゴリズムの解析に見られるような、 最適性と同じ概念です。 しかし、均衡は、1つ前のFAQに書かれている、 計測困難なフォースというものに対して適用されるものです。 ある解法がフォースを最適に解決するということを分析的に「証明する」ことは たいていは不可能です （実際問題、ここで「証明」の概念を定義することは困難です。 またその証明にどんな利用法があるのか見ることすら困難です）。 その一方で、 解法について誤った・怪しげな正当化を行うような 「とにかくこうなんだ」というストーリーを思いつくのはとても簡単です。 最高に良心的なパターン作者であっても、 ある解法がどうしてそれほど有効に機能するのかを 完全に理解しているわけではありませんし、 応用の可能性を完全に理解しているわけではありません。 かつてRalph Johnsonは次のような投稿をしました。 あるパターンが解く問題をはっきり理解するのは、困難なことが多いです。 しょっちゅう目にするので「これはパターンだ」ということはわかります。 それから、そのパターンを導入して外界がよりよくなれば、 「これはよいパターンだ」ということもわかります。 しかし、外界の方を見た場合、 どうして物事がそのようになっているのかを理解するのは難しいものです。 あるパターンが解く問題をはっきり理解する方法というのは、 事物を設計するときに自分自身を見ることだ、と私は思います。 あるパターンを私たちが使うのに、 どんな条件がきっかけとなるのでしょうか。 パターンが解く問題についてAlexanderが記述しないことがあるのはなぜかというと、 実は彼自身も知らない場合があるからなのだ、と思います。 GoFの本が問題についてあまりよく書いていない理由も、 これと同じに違いありません。 〔パターン記述の〕フォーマットのせいで著者が問題を無視してしまった、 ということではありません。 問題に対する著者の理解の結果が、 彼らの採用しているフォーマットとなったということなのです。 こういった理由から、パターンのコミュニティは、 議論が以下のようなものでバックアップされて いることを期待しています。 「よい」ことの経験的な証拠 その解法は、適用可能な複数のコンテキストで使われたことがあるかという点。 判断基準として、3個ルールが使われることがあります。 3個ルールというのは、 互いに独立した利用法を3個見つけるまで「これはパターンだ」と主張するな、 というものです。 〔訳注： Rule Of Three --- Wiki〕 比較 他の既知の解法やプラクティスとの関係。 適切な解法が適用されなかった場合の弱点や失敗を示す例も含むでしょう。 パターンを原作者から独立させる パターンというものは、最初に発案した人、 あるいは最初に実装した人だけによって書かれるべきではない。 レビュー その分野に密接に関わっている人々と、 そうではない人との両方を含んでいる、複数グループによる批評。 パターンをレビューするのによく使われるフォーマットの1つは、 Writer's Workshopです (これはPattern Languages of Programs(PLoP) カンファレンスで使われたものです)。 〔訳注： このWriter's Workshopはリンクが切れています。 どなたか適切なリンクを探してほしいです。 PLoPで使われているパターン記述のフォーマットです〕 パターンであるという証拠が提供されるまで、 パターンはプロト・パターン(proto-pattern) と呼ばれることもあります ―― パターン候補ということです。

パターンは、何々をしては「いけない」と、 否定的な形式になることがありえるでしょうか？ たぶん、理想的には、そういうことはありえません ―― 良いパターンの集合があれば、 あなたが直面するであろう無数の悪いデザイン （アンチパターンといわれることがある） を避けることができるでしょうし、 さらに、与えられたパターンを適用するのに不適切なコンテキストも すべて避けることができるでしょう。 しかし、非常に悪いのに 広まり過ぎているアイディアについては、 はっきりと言及しておく価値があります。 そうするための一つの方法は、 パターンの記述に「よくある罠と落とし穴」というセクションを含めることです。 悪い解法（不適格な方法）の記述は、 良い解法への動機付け、論理的根拠付け、フォースの一部になり得ます。 パターンは、悪い解法を良いものに変える方法を述べる場合もあるでしょう （「修正前／修正後」や「修理」というセクションなどで）。

パターンは、1つの解法だけではなく、いろんな他の解法群も提供してくれますか？ たぶん、理想的にはそうはできません ―― それぞれの解法は、 その解法を最もよく適用できるコンテキストに束縛されていなければならないのです。 しかし、常にそのようにするのは難しすぎます。 他の解法については、 述べないよりも、述べた方がいいでしょう。 なぜなら、 他の解法との違いの原因となっているフォースを発見することで、 さらなる改善を行う足場を築くことになるからです。 たとえ、他の解法が本質的には違っているとしても、 ほとんどのコンテキストとフォースを共有する一群のパターンを、 1つのプレゼンテーションの中にグルーピングすべきか、 というパターン記述の様式上の問題は残ります。

結局のところ、 うちのおばあちゃんに聞けば 教えてくれるようなアドバイスになるだけなのに、 手間ひまかけてパターンを書くのはどうしてですか？ パターンの中には、 あなたのおばあちゃんですら知っているくらい とても良くて役に立つものがあるからです。 パターンを書くことによって、 そのアドバイスのコンテキスト、価値(value)、そしてその意味(implications)が おばあちゃんのアドバイスよりも明確になるのです。

すべてのパターンは、[○○パターン]と同じくらい[低レベル/高レベル/一般的/ 特定的/抽象的/具象的]でなければなりませんか？ もちろん、そんなことはありません。

パターンを「ある特殊な形式や表記法」で表現することが出来ますか？ 自由に試してください。 しかし、もしも、 コンテキストの記述、 解決する問題、 解法の妥当性を示す証拠、 構築や実装のためのガイドライン、 あるいは、他のパターンとの関連を書き落としていたら、 その「形式的な表記法によるデザインの表現やデザインルール」は「パターン」 にはならないということは心に留めておいてください。

どうしてパターンを用いるべきなのでしょうか？ よくできたコードは再利用すべき、というのと同じような理由です。 すなわち、他の人の知識や経験から恩恵を受けようということです。 その人は、コンテキスト、フォース、そして解法を理解するために、 あなたがこれまで、あるいはこれから行う努力よりも 大きな努力をしてきたのです。 さらに、パターンはコードよりももっと再利用がしやすいのです。 というのは、パターンを適用することで、 既存のコンポーネントが再利用できないような特殊な状況を扱う ソフトウェアを作ることができるのです。 さらに、パターンを使うと、 開発者たちは 共通の開発上の問題を取り扱う、 共通の名前と概念の集合を得ることができます。 要するに、コミュニケーションが強化されることになるのです。

もし、パターンベースのCASEツールがあったら素敵じゃないでしょうか？ いいかもしれません。 でも、パターンは人と人とのコミュニケーションのためのものです。 もしもそのツールが、他の人たちとのコミュニケーションを促進するならば、 それはよいものです。 でもそのツールが、 パターンがねらいとしていることを、 コンピュータで実行可能にするというだけなら、 それはよいものとはいえません。

パターン・ランゲージとパターンの集合との違いは何ですか？ パターン・ランゲージは、相互に関連したパターンの集合です。 個々のパターンはみな同じコンテキストの一部を共有し、 いくつかのカテゴリーに分類されているかもしれません。 この用語はAlexanderに拠ります。 Alexanderの「ランゲージ」という用語の使い方は一般的ではありませんが、 誤りというわけでもありません。 もしパターンの集合を見て、非常に形式的にとらえなおすなら、 個々のパターンは「生成規則」だといえます。 もし、あなたがオートマトン理論を覚えているならば、 生成規則のセットが帰納的可算言語を特徴付けるひとつの手段であることを思い出すでしょう。 〔オートマトン理論で「生成規則」の集合が「言語」を定めるように、 「パターン」の集合が「パターン・ランゲージ」を定めることになるのです〕。

なぜもっと「なになに」に関するパターンがないのでしょうか？ なぜなら、あなたがそれを書いていないからです。 興味を持っているなら、あなたは何かを知る可能性が高くなります。 そして何かを知ったなら、あなたはパターンを書くことができるのです。

わたしが持ってる アイデア／デザイン／作ったもの が、パターンかどうか、どうすれば分かりますか？ それをパターンとして 書いてみてください。

パターンは、何個あるのですか？ 誰もが知っていなくてはならないパターンのうち、 まだ発見されていないものはほとんどない、と考えている人もいれば、 各分野に固有の文書化すべきパターンは もっとずっと多いと考えている人もいます。 おそらくどちらも正しいのでしょう。 パターンを書いてみてください。 そうすれば、新しいパターンを発見できるでしょう。

あまりにパターンが多すぎて、 パターンの発見や分類、索引付け、利用、 それから保守などの際に問題を引き起こすことになりませんか？ なるかもしれません。

[ある特定のオブジェクト指向分析/設計手法]の中で、パターンを利用できますか？ おそらく利用できるでしょう。 けれども、パターンを利用した場合、 その表記法の範囲を越え、 その手法にほとんど従わないことになるかもしれません。

パターンというのは、 必ず繰り返して使わなければならないんですか？ あなたが、とてもラッキーで、 直面している問題に対する完全なパターンのセットがすでにあって、 その問題に対しては次から次へと流れるようにパターンを応用することができ、 一度も後戻りせずに最終製品までたどり着く、 なんてことも原理的にはありえるでしょう。 でも、実際にはそんなにラッキーなことは決してありません。

パターンをうまく活用する、お勧めの開発プロセスはありますか？ おそらくあるでしょう。 しかし、この件についてたくさん議論しても、 パターンを活用した開発プロセスが何であるかは分からないでしょう。 まずは、実際にパターンを使ってみてください。 そうすれば、パターンを活用した開発プロセスが見つかります。

パターンを利用すれば、経営の実践や、 ソフトウェアの経済性に何か効果はありますか？ 31の回答と同じ答えです （まずは、実際にパターンを使ってみてください。 そうすれば、効果があるかどうかが分かるでしょう）。

既存のパターン群を使うことを人に教えるよりも、 新規のパターンを書くことを教える方が役に立つのではないでしょうか？ その両方が必要です。 どちらか一方がより必要性が高いということはありません。

どうすれば、自分の職場で、 組織的にパターンを利用できるでしょうか？ 一般に、次のことがお勧めできます。 パターンについてあなたがもっている最善のコードを掘り出しなさい。

設計文書とレビューを拡張して、デザインパターンも扱うようにしなさい。

既存のデザインパターンの利用に関する講習会を開きなさい。

パターン作者のワークショップで、既存のパターンをレビューしなさい。

設計を文書化するときには、パターン指向のスタイルテンプレートを使いなさい。 そうすると設計がパターンへ発展する可能性があります。

研究グループを形成しなさい。そして週に一度パターンについて話し合うために集まりなさい。 ひとたび熱狂的な人の集まりができたら、 その人たちは組織的に行うことを自然と求めるようになります。

どうしてAlexanderのパターンは建築家の間で広く使われていないんですか？ 理由は一つだけではないようです。 人々は次のような要因を挙げています。 永いあいだに培われたプラクティスと建築家のプロフェショナルとしての文化との軋轢（あつれき）、 経済的な要因、 Alexanderが、人々に自分の独自の家を設計し建築させることに焦点を当てているという事実、 そして『パターン・ランゲージ』に書かれている特定のパターンが、 どれだけ良くどれだけ役に立つのか意見が分かれている点、 などです。

非常に大規模な開発でも、パターンは使えますか？ 実際にそうしているという報告があります。

パターンは、騒がれすぎではありませんか？ もちろんそうです。これは避けられません。