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

2007/12/4

最近はめっきり本番用のコードを書いてない。 ただ、コードは書いている。書籍の内容を説明するためのコードだ。これに何時間もかけている。 書籍用のコードは本番用のコードとは違うので、考慮すべき点も違ってくる。

まずは、言語の選択だ。 書籍用のコードは、多くの読者が読める言語で書く必要がある。 内容はできるだけプラットフォームに依存しないようにしているが、コードは正確でなければならない。 そのため、みんなが理解できる言語を選択する必要がある。

その昔、オブジェクト指向の2大言語はSmalltalkとC++だった。 どちらもイマイチなところがあって、Smalltalkは知らない人には読みにくいし、C++は正確に書くことが難しかった★。 Javaの登場は天からの恵みだった。 C/C++を知っている人ならJavaのコードを読むことができた。 Smalltalkerたちも、鼻をつまんではいたが、コードの内容は理解していた。 著書『リファクタリング』でJavaを使ったのはこのためである。

後に.NETが登場した。 C#とJavaはほとんど同じなので、両者を交互に利用することができるようになった。 2つの言語を使うと、書籍の内容がどちらの場合にも役に立つことが分かるので、私は好んで使っている。

しかし、こうした状況は、少し難しくなってきている。 DomainSpecificLanguageの説明が難しいのである。 JavaやC#は★diverging★で、私が説明したいことに必要な機能を備えていないことがある。 個人的なプログラミングはほとんどRubyでやっているが、DSLにはこのRubyが適している。 以上のことから、私が最初に選んだ言語はRubyだった。 しかし、それ以外の言語も役に立つことがある。 いろんな言語でごちゃまぜにならないように気を配りつつ、 様々な言語を使ってDSLを表現できるようバランスをとる必要がある。

それから、書籍用のコードでは、馴染みのない言語機能は使わないようにすべきである。 ここで「馴染みのない」とは、その言語に精通している人にとってではなく、普通の読者にとって馴染みのないことを指している。 たとえば、Rubyでコードを書くとき、私はCollectionClosureMethodを使わないようにしている。普段は多用しているのだが、中括弧言語から来た人たちには分かりにくいからだ。 Rubyの流暢さを犠牲にしても、読者に分かりやすいほうがよいのである。

ただこれも、DSLを説明するときは判断が難しい。 内部DSLでは、読みやすさのためにネイティブの文法を使うことが多い。 言語の機能を犠牲にしすぎると、これが使いにくいものとなってしまう。 ここでも、DSLコードの読みやすさと言語の使いにくさとのバランスをとる必要があるのだ。