コード例

私はデザインについて書いており、やや抽象的なデザインパターンについて議論する場合でも、ソースコードの例を提供することが有益であると考えています。もちろん、これにより、コード例がパターンであると考える人もいるかもしれませんが、コードが提供する正確さによって、そのリスクは相殺されると思います。私はアイデアが確信できない時でも、コード例はそれを明確にするのに役立ちます。したがって、デザインに関する私の文章では、常にコード例を提供するように努めています。

コード例を示すにはいくつかの方法があります。多くの読者は、複数のアイデアがどのように相互接続するかを示す完全な例を好みます。私は異なる方法を取ります。私は、一度に1つのアイデアだけを示す、非常に小さな焦点を絞った例を好みます。

複数のコンセプトを示す現実的な例の問題は、例を理解するにはすべてのコンセプトを理解する必要があるため、理解が難しいということです。焦点を絞った例では、1つのことだけに集中できます。しかし、焦点を絞った例では、コンセプトがどのように組み合わさるかを見ることはできません。理想的には、個々の要素のための焦点を絞った例と、それらがどのように組み合わさるかを示す相互接続された例の両方を提供する必要があります。私は両方を行うエネルギーがないことを告白します。したがって、焦点を絞った例だけを示します。基本的なパターンを把握すれば、例を組み合わせるのが簡単になると考えています。また、他の著者は私のものを基にして、相互接続された例を提供することができます。（相互接続された例は、私が代替のパターンを示すことを好むという事実により、さらに困難です。これにより、大きな例で示す必要のある相互接続の組み合わせが増えるためです。）

焦点を絞った例のコツの1つは、例のポイントに注意を集中させることです。したがって、私が行うことの1つは、他のすべてをシンプルにして邪魔にならないようにすることです。つまり、コアな問題の理解を混乱させる可能性のある他のパターンは使用しないということです。たとえ実際のシステムで使用するとしてもです。この例としては、P of EAAのオブジェクト関係マッピングパターンがあります。オブジェクトとデータベース間のデータ転送をハードコードする多くのマッピングパターン（外部キーマッピングなど）を示します。しかし、多くの現実的なシステム（そして確かにORツール）では、これらの転送をハードコードするのではなく、メタデータマッピングを使用します。私はそれらをハードコードされた転送として示します。これは、何が起こっているかを理解しやすく、また、メタデータマッピングを理解しなくても外部キーマッピングを理解できるようにするためです。

物事をシンプルに保つことのもう1つの結果は、実際にはエラー処理が必要なはずのエッジケースを無視することです。これについては少しぎこちなく感じています。ここには、コード例をシンプルに保つことと、コード例が適切な習慣を示すことを保証することの間で緊張があります。

これは、ダウンロード用のコードサンプルを提供しない理由に関連しています。ダウンロードを避ける理由は、使用するコード例には、パターン以外の領域に多くの文字列とダクトテープが含まれているためです。たとえば、静的フィールドからの挿入IDの生成などですが、これは実際のシステムでは絶対に実行してはなりません。単純な例では簡単だからそうしていますが、本の中で足場を示していません。

また、コードをダウンロードしてもポイントがずれているのも事実です。コード例のポイントは、コード自体ではなく、コードが表現するアイデアです。理解するには読む必要があり、自分のアプリケーションに直接投げ込むことはできません。コードをダウンロードする利点の1つは、コードがどのように機能するかを理解するためにステップ実行できることです。それは正当な点ですが、ダクトテープはむしろこの効果を台無しにします。ダウンロードされた例は、焦点を絞った例よりも相互接続された例に適していると思います。