http://martinfowler.com/bliki/CodeExamples.html

抽象的なデザインパターンについて議論するときにも、サンプルコードは有用だというのが私の考えだ。もちろんそれではコードがパターンだという誤解を招くことになるだろう。しかし、それでも、コードによって詳しく述べた方が良いと思う。たまに考えに自信がないときがあるが、それもコードがあればはっきりくっきりする。なので、設計について書くときはいつもサンプルコードを載せるよう心がけている。

サンプルコードにも種類がある。多くの読者は完全なサンプルコードを好むだろう。これは複数の考えが絡み合っている類のものだ。しかし私は別の方法を採っている。焦点を絞った小さなサンプルコードを使い、一度にひとつの考えを表すようにしている。

現実的なコードは複数の考えを示してはくれるが、なかなか理解しにくい。というのも、サンプル内にあるすべての考えを理解しなくてはならないからだ。それに引き換え、焦点を絞ったサンプルであれば、そのひとつの考えに集中することが出来る。ただそれだと、複数の考えがどのように結びつくのかということが見えなくなってしまう。理想を言えば、両方提供するのがベストだろう。だが正直言って、私にはそんなことやってる余裕はない。というわけで、焦点を絞ったサンプルコードだけをお届けしているという塩梅だ。基本的なパターンを押さえていれば、サンプルコードを組み合わせることはなんてこたないだろう、というのが私なりの結論である。私の素材を使って結合したサンプルコードを作ることだって可能だし（結合させたサンプルコードの作成は大変だと思う。それは、私は代替パターンを示すのが好きで、それにより示さなければならない結合の組み合わせが増えるからだ）。

焦点を絞ったサンプルコードを用いるコツは、サンプルが指すポイントに集中することである。私はポイント以外の部分をシンプルにして邪魔にならないようにしている。つまり、他のパターンを用いることをしないのだ。他のパターンを用いてしまうと、議論の中心がぼやけてしまう。実際のシステムでは一緒に使うようなパターンであっても、両者を混在させたりはしない。 P of EAA のパターン「オブジェクト−リレーションマッピング」パターンを例に挙げよう。ここでは多くのマッピングパターンを示している（例えば外部キーマッピングなど）。オブジェクトとデータベース間のデータ受け渡しであるこのマッピングパターンはすべてハードコーディングしている。しかし、実際のシステムでは（O/Rマッピングツールでは）こういったデータ受け渡し部分をハードコーディングせずに、メタデータを用いてマッピングを行うだろう。私がハードコーディングを行ったのは、そうしたほうが何が行われているのか理解しやすいからである。また、メタデータマッピングを理解せずとも、外部キーマッピングを理解することもできるのである。

以上は、サンプルコードをダウンロードできないようにしている理由にも関係してくる。 ここで使ったサンプルコードには、パターン部分以外にも「文字列」や「ダクトテープ」が含まれている。例えば、静的なフィールドからIDを生成していく類のものだ——こんなこと実際のシステムではやっちゃだめだよ。私がこれらを用いたのは、シンプルなサンプルを作りやすかったからに他ならないわけで、こういった本の「裏側」なんか見せたくはない。

他にもサンプルコードをダウンロードできないようにしている理由がある。 サンプルコードの肝は、コードの指し示す「考え方」であって、コードそのものではない。 考えを理解するためにコードを読むのであって、コードだけ読んでそのまま自分のアプリケーションに適応するなどは出来ない。コードがダウンロードできれば、コードを見ながらどのように動くかを理解していけるじゃないか。至極まっとうな意見だが、ダクトテープがあってはそのメリットも台無しだろう。相互的なサンプルコードだったらダウンロードするメリットもあるだろうが、焦点を絞ったサンプルコードはダウンロードしないほうがいいだろう。