ソフトウェアパターンの記述

Patterns versus Recipes（パターンとレシピ）

人気があり、非常に効果的な技術文書の形式は、クックブックスタイルです（例：The Perl Cookbook、Rails Recipes）。クックブックとパターンブックには多くの類似点があります。どちらも問題解決スタイルを重視しています。

語彙を構築するという概念において、2つの間に大きな違いがあることがわかります。レシピはより具体的であり、通常は特定のプログラミング言語とプラットフォームに関連付けられています。パターンがプラットフォームに関連付けられている場合でも、より一般的な概念を説明しようとします。

この結果、レシピはパターンにおける解決策の焦点よりも、問題の焦点が強くなります。

私の執筆の関心はパターンにありますが、これは2つのスタイルの相対的な有用性に関する判断ではなく、一般的な設計原則への関心を反映しています。どちらも同じ基本的な理由で効果的です。どちらも、誰かが今日やりたいと思っている具体的なことに基づいてチャンク化されます。その結果、私は両方とも非常に効果的だと感じています。素晴らしい原則を学ぶこともできますが、特定の質問への回答があなたをテーブルに連れて行きます。

Patterns are Solutions（パターンは解決策である）

パターンについて書かれたほとんどすべてのものには、「パターンは問題の解決策です」のような定義があります。私はその声明に反対しませんが、パターンは主に解決策に関するものであるという点を過小評価する傾向があると思います。

パターンにはある種の神秘主義がつきまとう傾向があるため、これを言うことが重要だと思います。その神秘主義を切り抜けるために、パターンを書くことの全体のポイントは、繰り返し発生する有用な解決策を記述することであることを忘れてはなりません。成功はすべて、他の人が適切なときにその解決策を複製できる方法でそれを行うことです。他のすべては二次的です。つまり、パターンをどのように記述するか、どのような形式をとるかは、すべてこれをサポートする必要があります。私自身を含め、パターンライターが特定の形式に迷い、この単純な優先順位を見失ってしまうのを何度も見てきました。したがって、書くのが難しいときはいつでも、重要なのは解決策であることを忘れないでください。

そして問題は？さて、どんな解決策も問題の解決策です。対応する問題がなければ、どのように解決策を得ることができますか？問題（または問題、パターンは複数解決できます）を理解することは、解決策を理解する上で重要な部分です。問題について考えると、「解決策のコア」に焦点を当てることができます。また、ツール指向の議論に陥るのを避けるのにも役立ちます。したがって、問題を理解することは重要です。実に不可欠です。しかし、解決策はパターンの焦点であり続けるべきです。

An Evocative Name（示唆に富む名前）

パターン作業の価値ある特徴の一つは、作業方法について話し合うための語彙を開発することです。繰り返し発生するソリューションに名前を付けることで、私たちが通常苦労している技術的な問題を超えたソフトウェア設計の語彙を徐々に構築することができます。Javaのリスナーや.NETのデリゲートがオブザーバーパターンの実装方法の一部であることを知ると、それらをよりよく理解できます。 「オブザーバー」という名前は、新しい技術的概念（多くの場合、異なる技術では異なる名前が付けられています）を理解するための手がかりとなります。

良い名前を選ぶのは難しく、締め切り間際になっても名前を常にいじっていることに気づきました。それらは語彙になるので、良い名前を得るために多くの努力を払う価値があります。その経験豊富なベテランが何を言わなければならないかを考えてみてください。

結果として、名前は短くする必要がありますが、もちろん、簡潔な名前を思いつくのは困難です。良い1語のものはほとんど使われていると感じているため、私の名前は2、3語になる傾向があります。

何かを行うための代替方法であるパターンを見ると、共通の名詞を修飾する異なる形容詞を使用するのが好きです。そのため、ページコントローラーとフロントコントローラーは、コントローラーの2つの異なる形式です。厳密に言えば、それらはEAAのPにおける入力コントローラーの形式ですが、どうしても必要な場合（シングルテーブル継承とその代替案でそう感じたように）にのみ3語を使用します。

パターン名を**名詞句**にするのが好きです。パターンの価値ある特性の一つは、語彙を作成することです。そして、それは名詞を使用することでより簡単にできます。動詞は散文に合わせるためにより多くの文法的なバリエーションを必要とし、そのため名前を一貫して使用することが難しくなります。私は、老練な開発者が同僚に「ここでは*＜パターン名＞*を使用する必要があります」と語る姿を想像するのが好きです。

Why as well as how（方法だけでなく理由も）

ソリューションについて話すとき、ソリューション自体とソリューションの適用方法に焦点を合わせがちです。ソリューションがいつ適切で、どのような条件が適切か、または適切でないかについて話すのはより困難です。そのため、パターンの作成者は問題を強調します。それは、パターンのトリガーに私たちの心を集中させるからです。また、パターンの作成者がフォースについて話すのは、フォースがパターンの適応症と禁忌を探索する方法だからです。

パターンがあると思うときはいつでも、パターンを*使用しない*場合について考えようとします。これは多くの場合、代替パターンにつながります。そのため、私のパターンは多くの場合、代替パターンのグループで提供されます。

代替案の1つのセットのみを記述するパターン言語全体には特に懐疑的です。EAAのPのトリガーの1つは、J2EEに使用する唯一のアーキテクチャについて話している人々に対する私の苛立ちでした。ソフトウェアシステムは、エンタープライズアプリケーションなどの特定の領域内であっても、多様な世界に存在しています。物事を行う方法はたくさんあり、多くの場合、それらのほとんどは特定の状況では正しいです。「決してそうすべきではない」と思うときはいつでも、よく考えてみてください。時間があるかもしれません。そして、それはあなたを別のパターンに導くだけでなく、主要なパターンをよりよく理解するのにも役立ちます。

Code Examples（コード例）

多くの人は、パターン、特にコード例について心配しています。結局のところ、パターンとは、使用するたびに異なって見えるソリューションにおける深い類似性に関するものです。一部の読者が例をパターンとして捉え、パターンを美化されたマクロと考えてしまうのではないかと心配する正当な理由があります。

私の見解では、例によって物事をよりよく理解する人がたくさんいます。例が与えられると、彼らは一般的な原則の抽象化を開始できます。それは確かに私が働いているように見える方法です。そのため、例を避け、抽象化の中で読者を完全に失うよりも、例を示し、抽象化の欠如のリスクを冒したいと考えています。

パターンの特定の解釈について非常に懸念している場合は、複数の例を使用するのが効果的なアプローチです。同じパターンの異なる例は、共通のスレッドを説明するのに役立ちます。異なる例は、同じプラットフォームを使用するか、異なるプラットフォームを使用して異なるアプローチをとることができます。

もちろん、コード例には多くの詳細が含まれているため、コード例を見ない人もいます。その結果、コード例をスキップできるようにしようとします。つまり、コード例がなくても理解できるようにパターンを作成します。コード例はボーナスです。

コード例を作成する場合、どれほど複雑にするかという緊張があります。単純すぎると、現実的ではないとして却下される可能性がありますが、複雑すぎると、パターンを理解するために、パターンとは関係のない多くのことを理解する必要があります。十分に複雑になると、Micheal FeathersがMEGOポイント（「My Eyes Glaze Over」）と呼ぶものに到達し、それらを完全に失ってしまいます。私は単純すぎる側に誤ることを好みます。単純なことを明確にすれば、私（または他の人）は後でパターン間の相互作用を伴うより複雑なものを追加できます。多くを理解できないよりも、少しでも理解してもらいたいのです。この欲求は、パターンが対象とするチャンキングによって強化されます。読者は、パターンを理解するためにその1つのパターンを読むだけで済みます。

Alexandrian Form（アレクサンドリアン形式）

多くの人が、クリストファー・アレグザンダーの*A Pattern Language*（APL）をパターン界の重要な影響力と考えています。アレグザンダーは建築について書いており、ソフトウェアパターンの初期の支持者の一部に大きな影響を与えました。彼は独自のパターン形式でパターンブックを執筆しました。これは、ソフトウェアパターン界ではアレクサンドリア形式として知られています。彼の著書のパターンの他に、この形式の良い例は*Domain-Driven Design*にあります。ウェブ上では、Josh Kerievskyの*Knowledge Hydrant*パターンが良い例です。

多くの標準形式と同様に、実際には、アレクサンドリア形式にはかなりのバリエーションが見られます。APLの形式の説明を引用して説明します。

便宜上および明確にするために、各パターンは同じ形式になっています。まず、そのパターンの典型的な例を示す図があります。次に、図の後、各パターンには導入段落があります。これは、特定のより大きなパターンを完成させるのにどのように役立つかを説明することによって、パターンのコンテキストを設定します。次に、問題の始まりを示す3つのダイヤモンドがあります。ダイヤモンドの後には、太字の見出しがあります。この見出しは、問題の本質を1つか2つの文で示しています。見出しの後には、問題の本文が続きます。これは最も長いセクションです。パターンの経験的背景、その有効性の証拠、建物にパターンが現れる可能性のあるさまざまな方法などを説明しています。次に、見出しのように、再び太字で、ソリューション、つまりパターンの核心が示されています。これは、指定されたコンテキストで、指定された問題を解決するために必要な物理的および社会的関係の分野を説明しています。このソリューションは常に指示の形式で記述されているため、パターンを構築するために何をする必要があるかを正確に知ることができます。次に、ソリューションの後、メインコンポーネントを示すラベルが付いた図があります。

図の後、さらに3つのダイヤモンドがあり、パターンの本体が終了したことを示しています。最後に、ダイヤモンドの後には、パターンをこのパターンを完成させ、装飾し、完成させるために必要な言語のすべての小さなパターンに結び付ける段落があります。

-- [alexander-apl]

APLのパターンは、平均してそれぞれ6ページです。

アレクサンドリア形式は非常に物語的な形式であり、見出しは比較的少数です。その結果、読むとほとんどの代替手段よりも流れが良くなる傾向があります。問題と解決策の太字の要約文はよく目立ち、大量のパターンを非常に szybko スキップできます。

アレクサンドリア形式を使用するソフトウェアパターンでは、一般的なバリエーション（*Big Ball of Mud*で使用されています）は、メインセクション、つまり問題の本文を2つの部分に分割することです。最初の部分は、問題の見出しの後に、問題とその周辺の問題について詳しく説明します。2番目の部分は、ソリューションの概要の後に移動され、ソリューションの詳細について説明します。

リチャード・ガブリエルがこれを批判しているのを聞いたことがあります。それは、代替案とトレードオフの議論の多くを複製せざるを得ないという理由からです。以前はこれについてあまり考えていませんでしたが、彼に同意することに気づきました。本文を切り取ると、パターンの流れが途切れ、問題の半分または解決策の半分で問題について話し合う必要があるかどうかを心配するにつれて、よりぎこちなくなります。

ほとんどのパターンブックは、リファレンスブックのように、パターンを比較的自立したセクションとして編成しています。*Evans*は、パターンを一般的な物語の本の流れに埋め込んでいます。アレクサンドリア形式は、パターンの流れがより構造化されたパターン形式よりも物語的であるため、これを行うのに役立ちます。

GOF Form（GoF形式）

GOF形式は、パターンをソフトウェアの世界に実際に導入した、影響力のある*Gang of Four*の本で使用されている形式です。これは非常に構造化された形式であり、パターンを多くの見出しに分割します。意図、動機、適用性、構造、参加者、コラボレーション、結果、実装、サンプルコード、既知の使用法、および関連パターン。GOFパターンは非常に大きく、それぞれ12ページです。

Portland Form（ポートランド形式）

ポートランド形式は、最初のパターン会議でポートランドオレゴン州出身の数人がすべて同様の形式を使用したという事実からその名前が付けられました。優れたオンラインの例は[cunningham-checks]です。

ポートランド形式は完全にテキスト形式で非常に短く、通常はパターンごとに1ページ未満です。2、3段落で問題を説明し、次に、活版印刷で強調された「したがって」という言葉があり、その後に解決策を説明する2、3段落が続きます。

Coplien Form（コプリエン形式）

この形式は、Jim Coplien 氏と最も関連付けられているため、このように呼ばれています。Canonical Form（標準形）と呼ばれることもありますが、どのような標準を指しているのかは明確ではありません。オンラインで良い例としては、[coplien-fault-patterns] があります。

この形式にはかなりのバリエーションがあることを認識しています。重要な要素は、「問題」、「コンテキスト」、「フォース」、そして「解決策」という見出しのセクションです。ほとんどの著者は、いくつかの追加セクションも加えています。各セクションは数段落で構成され、フォースのセクションは一般的に箇条書きのリストになっています。この形式のパターンは通常、数ページとかなり短いです。

POSA Form（POSA形式）

この形式は、POSA の書籍に由来します。GOF と同様に、非常に構造化され、かなり大規模な形式ですが、見出しは異なり、「概要」、「例」、「コンテキスト」、「問題」、「解決策」、「構造」、「ダイナミクス」、「実装」、「解決された例」、「バリエーション」、「既知の用途」、「結果」、そして「関連項目」となっています。パターンは通常、12ページ強の長さです。この形式の重要な部分は、パターンに先立って、パターンを要約し、全体的なトピックを説明するナラティブ（物語）の章があることです。

P of EAA Form（エンタープライズアプリケーションアーキテクチャパターン形式）

これを標準形式と呼ぶのは、私以外誰も使用していないため、少し cheeky（生意気）です。しかし、私は長年パターンを書いてきて、さまざまなスタイルを試してきましたが、これが私が好むようになったスタイルです。「仕組み」、「いつ使うか」、そして1つ以上の「例」という、いくつかのセクションで構成された、かなりナラティブなスタイルです。長さは平均で約8ページですが、1ページから12ページをはるかに超えるものまでさまざまです。こちらが最近の例です。

Arranging Patterns into a Structure（パターンを構造化する）

人々が遭遇する一般的な問題は、作成しているパターンの構造化方法です。パターンはチャンキングを促し、チャンクに集中するのは簡単です。しかし、これらのチャンクをどのように意味のあるものにまとめるのでしょうか？多くの人がパターンコレクション全体の構造に苦労しているのを見てきました。

ここでの私の最大のアドバイスは、「心配しないでください。私も心配していません」です。私は、個々のパターンに集中し、遭遇する興味深い解決策を記述することを好みます。一連のパターンが集まり始めたら、それらをどのように構造化すべきかを考え、より多くのパターンでカバーする必要がある明らかなギャップを探します。

特に、パターンを掘り下げる前に、全体的な構造を正しくしようと多くの時間を費やす必要はありません。私は、パターンの詳細を記述するまで、実際にはパターンを理解していないことに気づきます。

最終的には、優れたパターンの集まりが整理されていない状態の方が、非常に優れた構造の下に弱いパターンがある状態よりも価値があることを忘れないでください。

Patterns and Pattern Languages（パターンと言語パターン）

私は、人々がパターンについて語る神秘主義に悩まされることがよくあります。この種のほこりを巻き上げる一般的な分野の1つは、パターンと言語パターンの問題です。これはしばしば、「これはパターン言語ではなく、単なるパターンのカタログに過ぎない」という言葉が伴います。

パターン言語の背後にあるアイデアは、再びアレクサンダーに由来します。そのアイデアは、パターンからパターンへと導く構造を持つパターン群を持つということです。あなたは（通常）いくつかの非常に戦略的なパターンから始め、各パターンは他のパターンを適用するかどうかを決定しなければならないポイントへとあなたを導きます。パターン言語には、さまざまなパターンをつなぐ流れがあります。

パターン言語が簡単に思い浮かぶなら、それでいいのですが、パターンの単なる緩やかなコレクションである本が悪いことだとは思いません。確かに私の本はどれもパターン言語ではなく、GOF もそうではありません。パターン言語を書くのは非常に難しいですし、人々がそれらをまとめようとして行き詰まっているのを見てきました。パターンの価値は、それらが伝える内容の有用性であることを忘れないでください。この意味で、私はパターン言語を構造化メカニズムと見なしています。そして、上記で述べたことと同じコメントが当てはまります。

(Knowledge Hydrant は、パターン言語の良いオンライン例です。)

Granularity of Patterns（パターンの粒度）

私が最も懸念している問題の1つは、自分のパターンを概念的にどれほど大きくするかということです。これは、書き上げるのに何ページかかるかではなく、パターンによってどれだけの概念的な領域がカバーされるかということです。

パターンを掘り下げ始めると、2つの関連する概念を別々のパターンにするか、単一パターンのバリエーションとして組み合わせるかを選択できることがよくあります。GOF からのこの良い例は、4つのバリエーション（リモートプロキシ、バーチャルプロキシ、保護プロキシ、スマートポインター）を記述するプロキシパターンです。これらを4つの別々のパターンとして、または4つのバリエーションを持つ1つのパターンとして、または4つのさらなるパターンを持つ1つの概要パターンとして書くことができます。

これに対する簡単な答えはありません。もしあるとしたら、それが何なのか知りたいです。パターンの境界線をどこに置くかを決定することは、私が取り組んでいる最も難しい問題の1つです。

私が主張する1つのことは、もしあなたがそれらを分割するならば、全体的なパターンを持たせようとしないでください。そのため、オブジェクトリレーショナルパターンで継承をマッピングするためのパターンに取り組んだとき、私は単一テーブル継承、クラステーブル継承、および具象テーブル継承のために異なるパターンを選びました。それらを結びつけるための全体的な「継承マッピング」パターンを持たせようとはしませんでした。これは、「いつ」セクションに重複があることを意味します。なぜなら、それぞれのケースで3つすべてのトレードオフについて説明する必要があるからです。私はそのような重複のいくつかに我慢できます（テキストをカットアンドペーストするのではなく、毎回異なる書き方をします）。私のスタイルでは、ナラティブに結びつきがあり、それがナラティブの目的の一部です。

Be Specific（具体的に）

パターンのレビューでよく出てくる質問は、あるドメイン用に書かれたパターンが他のドメインでも意味をなすように見える場所です。アリスはデータベースの相互作用に関するパターンを書き、ボブは同様のアドバイスがネットワーク通信にも当てはまると述べ、パターンをより一般的にすることを提案します。

一般的に、私はそのような一般化に抵抗します。重要な問題は、著者の経験です。アリスがデータベースについて知っていて、ネットワークプログラミングについて知らない場合、彼女が書くパターンはデータベースの状況を説明する必要があります。読者はそれを自分の専門分野に適用できると考えるかもしれませんが、それが適用できるかどうかを決定するのは読者次第です。そのような読者は、作者よりも判断を下すのに適した立場にあります。

Tasks rather than Tools（ツールではなくタスク）

ソフトウェアの作成における大きな災いの1つは、タスクではなくツールに焦点を合わせていることです。ツール指向の本は、「ここにツールボックスがあり、各ツールの使用方法を説明します」と言っています。タスク指向の本は、「あなたがする必要があるタスクがたくさんあります。ここでは、それらを実行する方法を示します（その過程でツールを示します）」と言っています。ツール指向は、特にソフトウェアマニュアルの場合、フレームワーク（たとえば）を見てツールを識別するのが簡単なので、書きやすくなっています。

しかし、タスク指向の方がはるかに優れています。人々は「このウィジェットをどのように使用しますか」と言って本に近づくのではなく、代わりに何らかのタスクを実行する必要があり、それを実行する方法を見つけようとしています。ツールブックを使用すると、役に立つ可能性のあるツールを探して時間を費やします。これはすべて問題ありませんが、代わりにタスクをすぐに見つけることができれば、はるかに優れています。レシピ指向の本が非常に便利なのはこのためです。それらはタスクに焦点を合わせています。

パターンは常に、ツール指向になる危険性を孕んでいます。結局のところ、パターンを用いることで私たちが行っているのは、概念的なツールを特定しようとすることだからです。そのため、書籍が新しく名前を付けたツールの使い方を示す、ツール指向のガイドになってしまうことは非常に容易に起こり得ます。

これが、パターンにおける「問題」の部分の重要性です。最終的にはツールを特定することになりますが、各パターン（ツール）が解決する問題について深く考えることで、ツール指向の危険性を軽減できます。パターンの境界を自由に設定することができます。実際、この自由こそがパターン作成を困難にしているのです。作業をできるだけタスク指向にするよう努めることで、これらの境界を有用な方法で描くことができます。

Nothing new here（ここでは何も新しいことはない）

パターンに関する書籍に対するよくある批判は、経験豊富な開発者にとって目新しい情報が何もないということです。これは事実であるだけでなく、パターンの本質でもあります。

パターンは、独創的なアイデアを提示するためではなく、現場の知識を捉えるためのものです。そのため、パターンに関する書籍が、ある分野で長年働いてきた人々に、驚くほど斬新なアイデアを追加することはないのは必然です。しかしそれでも、アイデアを学ぶ必要のない経験豊富な人々にとっても、パターンに関する書籍には重要な役割があると考えています。それは、経験豊富な人々が、自分たちの経験を周囲の経験の浅い人々に伝えるのを助けるという役割です。熟練した開発者だけで構成されたチームはほとんどありません。経験豊富なリーダーができる最も重要なことの1つは、自分のスキルを伝えることです。

そのため、自分が専門とする分野のパターンを評価する場合、新しいことを学ぶことを期待してはいけません。代わりに、そのパターンが自分の知識を他者に伝えるのにどのように役立つかを評価してください。パターンを自分で使用してみて、他の人が重要な概念を理解するのに役立つかどうかを確認してください。

これが、パターンの書籍は長く使えるべき理由でもあります。ソフトウェア設計の基礎の多くは、技術は急速に変化しても、それほど急速には変化しません。そのため、パターンの書籍が古くても、それほど心配する必要はありません。