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

デザインパターンFAQ

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

原文は Doug Lea<[email protected]> によってメンテナンスされています。

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

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

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

1. 「パターン」という用語によい定義がないのはなぜでしょうか？

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

   • コンテキストとは、 繰り返し発生する一群の状況のことを指します。 その状況にパターンを適用することになります。
   • 問題とは、 コンテキストで起きる一群のフォース ——目的と制約——のことを指します。
   • 解法とは、 これらのフォースを解決するために適用できる 正規化された設計の形、あるいは設計のルールのことを指します。

   定義に関するもっと広い議論は、 Patterns Home Pageと WikiWikiWebにあります。

2. こうしたものを記述するのに、「パターン」よりもいい言葉は使えないんですか？

   あなたの好きなように呼んでかまいませんよ。 でも、他の多くの人たちの呼び方を変えるにはもう遅すぎるでしょうね。

3. 「デザインパターン」は「パターン」とは違うんですか？

   パターンという言葉の表す概念はとても広いので、 どんな種類のコンテキストにも適用可能です。

   「ギャング・オブ・フォー」(四人組:GoF —— Gamma、Helm、JohnsonとVlissides)の 『デザインパターン』という本は、そのほとんどの記述を 「マイクロアーキテクチャ(「オブジェクト構造」とも言います)」 を扱ったパターンに費しています。 マイクロアーキテクチャというのは、 オブジェクト指向開発を行う場合によく見られる、 オブジェクト(や それらのクラス)の間の静的あるいは動的な関係のことです。 「デザインパターン」という用語はこのような種類のパターンを示すために 使われるようになっています。 この文献に記述されたパターンは、 もっとも一般的な種類のパターンとなっています。

   どう考えてもパターンとは言えない場合でも、 オブジェクト構造ならみな「デザインパターン」という用語を使う人がいますが、 これは誤りです。やめてください。

4. パターンは他のどんなものに適用できますか？

   ソフトウェア関連の既存の例としては、次のものがあります。

   プログラミングのイディオム

   例えば、C++での入れ子になったクラス、 Javaでのインターフェース、 Smalltalkでのカスケード呼出し(メッセージの流し込み)の特定の利用法です。

   コーディングのイディオム

   例えば、次のようなCのイディオムです。 while (*dst++ = *src++);

   データ構造

   例えば、木構造やバッファなどです。

   アルゴリズム

   例えば、並列処理のためのアルゴリズムなどです。

   プロトコル

   例えば、並列オブジェクトシステムなどで使われるプロトコルなどです。

   新しいフレームワーク開発

   例えば、ユーザインタフェース(UI)ツールキットのためのものです。

   既存のフレームワークの利用

   例えば、OpenDoc, JavaBeans, …。

   分析モデル

   例えば、課金ルールをどう取り扱うかといったことです。

   システムアーキテクチャ

   例えば、BlackboardやBrokerといったアーキテクチャです。 〔訳注：参考 http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/〕

   開発組織

   例えば、開発チームの構造や力学といったものです。

   開発プロセス

   例えば、オブジェクト指向分析設計における工程や戦略といったものです。

   さらにパターンは、ソフトウェア開発以外のいくつかの分野にも適用されています。

5. パターンとコーディングのイディオムとの違いは何ですか？ デザインとの違いは？ OMTやUMLダイアグラムとの違いは？ ユースケースとの違いは？ プロトコルとの違いは？ アルゴリズムとの違いは？ ヒューリスティック(発見的手法)との違いは？ アーキテクチャとの違いは？ コーディング標準との違いは？ コーディングスタイルとの違いは？ 開発手法との違いは？

   パターンは主にそのうちの何か1つに関連しているものではありますが、 そのひとつだけではパターンとは言えません。 パターンとは、 それらを実際の開発現場に適用する方法と理由を示すガイダンス を提供するものです。

6. パターンとクラスの違いは何ですか？ 再利用可能なコンポーネントとの違いは？ パラメータつきの(テンプレート)クラスとの違いは？ クラスライブラリやパッケージとの違いは？ フレームワークとの違いは？ ツールとの違いは？ コード生成器との違いは？

   パターンは実装ではありません。 実装や他の技術的な製品を生み出す際の「いつ、なぜ、どうやって」を示すものです。

   実装(クラス、フレームワーク、ツールなど)を使った記述が適した解法もあります（多くはないです）。 その場合、実装を通して、 知るべきことや行うべきことが開発者に全部伝わってしまう、 ということになります。 たとえそうだとしても、コード自身はパターンではありません。

7. パターンとハウツーガイドとの違いは何ですか？

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

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

   いくらか重なりあう部分があるようです。

9. XXXのパターンについて書いてある印刷物やオンラインの情報はどこで手に入りますか？

   パターン情報センターのような機関はありません。 でも、パターンの情報を探すことはそれほど難しくはありません。 いくつかのスタート地点を挙げてみましょう。

   • Hillside Patterns Home Page
   • Linda Risingの本 『The Pattern Almanac』 (またそのひとつ前の『The Patterns Handbook』)、この本には、公開されている大部分のパターンについてのリファレンスが載っています。
   • Wiki
   • Pattern Depot（パターンの倉庫）
   • Open directory
   • あなたのお気に入りのサーチエンジン
10. Christopher Alexanderというのは誰ですか？

    Alexanderは、パターンを考案した（ソフトウェアではなく建築物の）建築家です。 短い経歴と、関連した読み物やWebページへのリンクは、 Salingaros's Notes on Christopher Alexanderにあります。

11. パターンを記述するのに最適なフォーマットは何ですか？

    自分で選んでください。 Alexanderのパターンのほとんどすべては、 次のような形式で記述されています。

        [もしも]  ある[コンテキスト]で
                  ある[例]のような
                  [問題]が
                  [フォース]を伴って現れた
        [ならば]  いくつかの[理由]で
                  [デザインのフォームやルール]を適用して
                  [解法]を組み立て、
                  さらに[新たなコンテキスト]や[別のパターン]へ導く
    

    様式上、多くのバリエーションがあります。 パターンについて書いている既存の本で、 完全に同じフォーマットを使用しているものは2つとありません。 フォーマットの中には、 純粋に物語のような形式になっている Portland Formもあります。 おそらく最も一般的なフォーマット（ デザインパターン本で使われている）は、これの逆で、 デザインのフォームやルールの記述から始まって、 問題や、コンテキストや、そのパターンを適用できる例題がその後に記述されています。

    パターンの構造と内容を記述する際には、 形式の違いによらず以下の要素が必要になります。

    最良のプラクティスの記述

    あるいは、少なくとも一般に受け入れられているプラクティスの記述が必要です。 ある人たちは、パターンを、決定的なソフトウェア・エンジニアリングのハンドブックの作成に向けたステップだと見ています。

    適切な一般性

    そのパターンが繰り返して起こるという証拠が必要です。 たいていの場合、 よく知られている用例を何個か要約することが必要となります。 また、そのパターンを適用できない状況について言及することも必要かもしれません。 その場合には、替わりのパターンへのリファレンスも含める必要があるでしょう。

    スコープ

    誰かがそのパターンを適用したいと思うコンテキストを、詳しく記述します。 また、そのパターンが結果として別のパターンの応用例となることが多いなら、 そちらのパターンへのリファレンスも含めます。

    建設性

    パターンというものは、 人々がその解法の実例を1つ作り上げるような形で表現されます。 本質がどこにあるかを示す関係図が必要になるかもしれません。 また、パターンの利用者が従わなければならない一連の設計工程が必要となるかもしれません。 その場合には、解法のフォームの記述や例示も必要となるでしょう。

    完全性

    関連するすべてのフォースが記述されているということです。

    有用性

    その解法がうまくフォースを解決できるという証拠です。 もしフォースの一部分しか解決できない場合や、 その解法が新たなフォースを生み出す場合には、 適用できる関連パターンへのリファレンスが必要です。

    実例

    解法のステップを示した実例と、 既存のソフトウェアの文書化された使用法の両方です。

    適切なレベルの抽象化

    例えば、 「他のレベルの間接的な手法を加えながら」 というのは発見を促すのに有用な表現ですが、 一般的過ぎるし、複数の側面を持ち過ぎているので、 よいパターンとはいえません。

    オリジナリティの欠如

    新たな解法は、パターンではありません （しかし、要約・統合・焼き直しをしてパターンとしての記述を導くことは 目新しいものかも知れません。 また、パターンは新たな用途を導き出すかも知れません）。

    適切な名前

    共有されるボキャブラリを開発者に提供する、 簡潔で対象をよく言い表わした名前です。

    明確さ

    人々は、 そのパターンを適用するどうか、 また適用するならどのように適用するかを、 パターンの表現方法とスタイルによって簡単に判断することができ、 パターンを自分で「再発明」する必要がありません。

    〔訳注： パターン記述の例は、 デザインパターンのテンプレートを参考に〕

12. 「フォース」とは何ですか？

    ソフトウェアエンジニアが設計や実装の正当性を示すときに使っている判断基準の類いを、 フォースという概念は一般化します。 例えば、コンピュータサイエンスにおけるアルゴリズムの古典的な研究において、 解決すべき主要なフォースは「効率」（時間的な複雑さ）です。 しかしながら、パターンというものは、 これまで生み出してきたあらゆる作品の開発においてあなたが遭遇したような、 さらに広範囲で、さらに計測が困難で、互いに矛盾した目的と制約を取り扱います。 例を以下に示します。

    正当性

    • 解法における完結性と完全性
    • 静的な型の安全性、動的な型の安全性
    • マルチスレッドでの安全性、生存性
    • フォールトトレランス、トランザクション性
    • セキュリティ、頑健性(ロバスト性)

    〔訳注： 型の安全性については例えば、 ParcPlace Type-Safety Discussionを参照してください。

    生存性(liveness)とは、 例えば「スレッドがデッドロックに陥ったり、 入りたいクリティカルセクションにいつまでも入れなかったりすることのない」 性質のようです。

    トランザクション性(transactionality)とは、 「一連の処理がすべて 完全に実行されるか、すべて取り消されるかの どちらかという性質」のようです。 解説1 、 解説2 、 解説3、なども参考に。

    フォールトトレランス(耐障害性) Fault Toleranceの解説はこちらです。 〕

    リソース

    • 効率: パフォーマンス、時間的な複雑さ、送られるメッセージの数、必要となる帯域幅
    • 空間の利用率: メモリ量、オブジェクトの数、スレッドの数、プロセスの数、通信チャネルの数、プロセッサの数、…
    • 漸増性(?)(Incrementalness): (オンデマンド、必要に応じて処理を開始すること)
    • ポリシーの力学: 公平性、均衡性、安定性

    構造

    • モジュール性、カプセル化、カップリング(coupling〔訳注：何かを直すと、別のものも常に対応して直さなければならない状況〕)、独立性
    • 拡張性: サブクラス化のしやすさ、調整のしやすさ、発展性、保守管理のしやすさ
    • 再利用可能性、開放性(openness)、構成のしやすさ、ポータビリティ（可般性、移植可能性）、組み込みやすさ
    • コンテキストへの依存
    • 相互運用性
    • …そのほかの「〜性（〜しやすさ）」や「品質を左右する要因」など

    構成

    • 理解しやすさ、小ささ(minimality、無駄なものがないこと)、簡潔さ、エレガントさ
    • エラーを起こしやすい実装(error-proneness)
    • 他のソフトウェアとの共存
    • 保守管理しやすさ
    • 開発プロセスの（への）影響
    • 開発チームの構成と原動力の（への）影響
    • ユーザ参加の（への）影響
    • 生産性・スケジューリング・コストの（への）影響

    利用法

    • 利用する際の倫理性
    • ヒューマン・ファクター(人的要因): 学習しやすさ、アンドゥしやすさ、…
    • 変化していく外界に対する順応性
    • 美学的側面
    • 医学的・環境的な影響
    • 社会的・経済的・政治的な影響
    • …人間存在に対するその他の影響

    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/〕

13. 「フォースの解決」とは何ですか？

    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) と呼ばれることもあります —— パターン候補ということです。

14. 無名の質(the Quality Without A Name (QWAN))とは何ですか？

    一言ではうまく答えられません。 The Timeless way of building(Alexander著、ISBN 0-19-501-919-9) を読まなくてはならないでしょう。 〔訳注： 『時を超えた建設の道』（鹿島出版会）平田翰那訳、ISBN4306043061〕

    「AlexanderはQWANについて、一言も書かなかったんだぜ」と、 たいそうオタクなパターン狂たちはうそぶきます。 「QWANは、言及するのをはばかりたくなるような、 神秘的で・奇妙に聞こえ・形而上学的なゴタクなら 何でもパターンを結びつけてしまう」と、 たいそうオッチョコチョイのパターン狂たちはうそぶきます。

    〔訳注： 『生成的開発プロセス・パターンランゲージ』(James O. Coplien)の中の「無名の品質」の部分が参考になるかもしれません。 〕

15. パターンは、何々をしては「いけない」と、 否定的な形式になることがありえるでしょうか？

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

16. パターンは、1つの解法だけではなく、いろんな他の解法群も提供してくれますか？

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

17. 結局のところ、 うちのおばあちゃんに聞けば 教えてくれるようなアドバイスになるだけなのに、 手間ひまかけてパターンを書くのはどうしてですか？

    パターンの中には、 あなたのおばあちゃんですら知っているくらい とても良くて役に立つものがあるからです。 パターンを書くことによって、 そのアドバイスのコンテキスト、価値(value)、そしてその意味(implications)が おばあちゃんのアドバイスよりも明確になるのです。

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

    もちろん、そんなことはありません。

19. パターンの理論的な基礎は何ですか？

    通常の意味でいう、定式化された基礎はありません。 パターンは、あらゆる種類の理論的・経験的な土壌から 発生したデザインの概念を表現することができます。 その一方で、パターン指向の設計の概念の多くは、 工学の広範な分野における「設計理論」についての古典的な研究から、 およびそれほど古典的ではない研究から発生しています（ the Patterns Home Pageの参考文献にリストアップされている論文を参照してください）。

20. パターンを「ある特殊な形式や表記法」で表現することが出来ますか？

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

21. どうしてパターンを用いるべきなのでしょうか？

    よくできたコードは再利用すべき、というのと同じような理由です。 すなわち、他の人の知識や経験から恩恵を受けようということです。 その人は、コンテキスト、フォース、そして解法を理解するために、 あなたがこれまで、あるいはこれから行う努力よりも 大きな努力をしてきたのです。 さらに、パターンはコードよりももっと再利用がしやすいのです。 というのは、パターンを適用することで、 既存のコンポーネントが再利用できないような特殊な状況を扱う ソフトウェアを作ることができるのです。

    さらに、パターンを使うと、 開発者たちは 共通の開発上の問題を取り扱う、 共通の名前と概念の集合を得ることができます。 要するに、コミュニケーションが強化されることになるのです。

22. もし、パターンベースのCASEツールがあったら素敵じゃないでしょうか？

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

23. パターン・ランゲージとパターンの集合との違いは何ですか？

    パターン・ランゲージは、相互に関連したパターンの集合です。 個々のパターンはみな同じコンテキストの一部を共有し、 いくつかのカテゴリーに分類されているかもしれません。

    この用語はAlexanderに拠ります。 Alexanderの「ランゲージ」という用語の使い方は一般的ではありませんが、 誤りというわけでもありません。 もしパターンの集合を見て、非常に形式的にとらえなおすなら、 個々のパターンは「生成規則」だといえます。 もし、あなたがオートマトン理論を覚えているならば、 生成規則のセットが帰納的可算言語を特徴付けるひとつの手段であることを思い出すでしょう。 〔オートマトン理論で「生成規則」の集合が「言語」を定めるように、 「パターン」の集合が「パターン・ランゲージ」を定めることになるのです〕。

24. なぜもっと「なになに」に関するパターンがないのでしょうか？

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

25. パターンを新たに書き下ろすにはどうすればいいですか？

    以下のことをお勧めします。

    • パターンについて書くのは避けましょう。パターンをただ書きましょう。
    • あなたが知っているものを取り上げ、色々な事例や記述を探します。もしくは、既存のソフトから新しいパターンを掘り出します。
    • 同じようなパターンを他の人が作っていないか探しましょう。
    • パターンの質にねらいを定めましょう。量ではありません。
    • そのパターンが存続し、適用されるべき理由を明確にしましょう。
    • そのパターンを書くに当たってのフォーマットを選びましょう。
    • ほかの人に配布（たとえばWebページ、パターンディスカッショングループ、メーリングリストへの投稿などへ配布）して、コメントをもらいましょう。
    • パターン作者のワークショップで検討してもらうことができるようなグループに、あなたの書いたパターンを提出してみましょう。例えばPLoP(Pattern Language of Programming)などがあります。
    • 継続的に見直し、洗練させていきましょう。

    Ward Cunninghamの、 Tips for Writing Pattern Languages (パターン・ランゲージを書くコツ)もご覧ください。

26. わたしが持ってる アイデア／デザイン／作ったもの が、パターンかどうか、どうすれば分かりますか？

    それをパターンとして 書いてみてください。

27. パターンは、何個あるのですか？

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

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

    なるかもしれません。

29. [ある特定のオブジェクト指向分析/設計手法]の中で、パターンを利用できますか？

    おそらく利用できるでしょう。 けれども、パターンを利用した場合、 その表記法の範囲を越え、 その手法にほとんど従わないことになるかもしれません。

30. パターンというのは、 必ず繰り返して使わなければならないんですか？

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

31. パターンをうまく活用する、お勧めの開発プロセスはありますか？

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

32. パターンを利用すれば、経営の実践や、 ソフトウェアの経済性に何か効果はありますか？

    31の回答と同じ答えです （まずは、実際にパターンを使ってみてください。 そうすれば、効果があるかどうかが分かるでしょう）。

33. 既存のパターン群を使うことを人に教えるよりも、 新規のパターンを書くことを教える方が役に立つのではないでしょうか？

    その両方が必要です。 どちらか一方がより必要性が高いということはありません。

34. どうすれば、自分の職場で、 組織的にパターンを利用できるでしょうか？

    一般に、次のことがお勧めできます。

    • パターンについてあなたがもっている最善のコードを掘り出しなさい。
    • 設計文書とレビューを拡張して、デザインパターンも扱うようにしなさい。
    • 既存のデザインパターンの利用に関する講習会を開きなさい。
    • パターン作者のワークショップで、既存のパターンをレビューしなさい。
    • 設計を文書化するときには、パターン指向のスタイルテンプレートを使いなさい。 そうすると設計がパターンへ発展する可能性があります。
    • 研究グループを形成しなさい。そして週に一度パターンについて話し合うために集まりなさい。 ひとたび熱狂的な人の集まりができたら、 その人たちは組織的に行うことを自然と求めるようになります。
35. どうしてAlexanderのパターンは建築家の間で広く使われていないんですか？

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

36. 非常に大規模な開発でも、パターンは使えますか？

    実際にそうしているという報告があります。

37. パターンは、騒がれすぎではありませんか？

    もちろんそうです。これは避けられません。

38. パターンは本当に有効ですか？

    もっと具体的な質問にしてください。

原文はDoug Leaが書き、パブリックドメインとして公開されています。

Last modified: Tue Nov 7 07:27:54 EST 2000

この翻訳について

この翻訳は、 デザインパターン・メーリングリストの有志によって行われ、 結城浩がまとめました。 訳注は、有志からの情報を元に整理しました。 誤訳・改善案がありましたら、 デザインパターン・メーリングリストへご連絡ください。 翻訳に参加、意見投稿をしてくださった方のお名前を以下に列挙します（順不同、万一抜けがあったらご連絡ください）。 瀬戸さん、ヤスさん、中村さん、柴山さん、清水さん、上手さん、 さくさん、 Ｋ仲川さん、井芹さん、あまぴょんさん、 曾根さん、岡田さん、海内さん、重信さん、小竹さん、谷内上さん、 小山さん、みかままさん、沼田さん、永野さん。

この翻訳はパブリックドメインです。

訳語一覧

訳語は以下のように統一しています。

原語

訳語

Alexander

Alexander(人名)

analysis model

分析モデル

Christopher Alexander

Alexander(人名)

context

コンテキスト

design

設計（デザインの場合もある）

design pattern

デザインパターン

dynamic type safety

動的な型の安全性

equilibrium

均衡

fault tolerance

フォールトトレランス、耐障害性

force

フォース

force resolution

フォースの解決

idiom

イディオム

liveness

生存性

notation

表記法

object structure

オブジェクト構造

pattern

パターン

pattern language

パターン・ランゲージ

practice

プラクティス

problem

問題

QWAN

無名の質

robustness

頑健性、ロバスト性

rule of 3

3個ルール

recursively enumerable language

帰納的可算言語

step

工程(ステップの場合もある)

solution

解法

static type safety

静的な型の安全性

transactionality

トランザクション性

type safety

型の安全性

vocabulary

ボキャブラリ

修正履歴

• 2001å¹´7月25日、HTML 4.01 Validになるように修正。
• 2001å¹´6月22日、読者からのメールを受けて#5,#6に手を入れました。
• 2001å¹´6月16日、完成。プロジェクト杉田玄白に正式参加。
• 2001å¹´6月14日、Prof.Doug Leaの原文ページからリンクされています。
• 2001å¹´6月12日、大まかなブラッシュアップ完了。訳語一覧を更新。
• 2001å¹´6月11日、ブラッシュアップ中。
• 2001å¹´6月10日、ブラッシュアップ中。
• 2001å¹´6月9日、全体にいちおう手がつきました。
• 2001å¹´6月8日、#1〜#11,#12,#14,#15,#19〜#21,#24,#25,#27,#31〜#33,#36〜#38 (残り12個)
• 2001å¹´6月7日、デザインパターン・メーリングリストにて翻訳開始のアナウンス。

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