Designing a framework in an "open" way (オープンなフレームワーク設計)
"Beautiful Code" を読んでいます。
いいですねー。カーニハンやベントレー（『プログラマの打ち明け話』、『珠玉のプログラミング』、『プログラミングの設計と着想』など、昔ファンでした）の文章をひさしぶりに読みました。まだまだ、プログラミングにもわくわくすることが一杯ありますね。
ぼくが最も感動したは、Michael Feather （"Working Effectively with Legacy Code"の著者）の
"Framework for Integrated Test: Beauty Through Fragility"(英語GoogleBook全文)
です。コーディング（プログラム設計）に関する Ward Cuninngham の逸話はいくつもあります。November メソッドの話、400行の Perl で書かれた初版 Wiki の話、などなど。
今回は、Web ブラウザでテストが行える FIT というテスティングフレームワークの「設計」についてです。
通常のフレームワーク設計の前提ルール（属性はprivate、ホットスポットを用意し、そこをオーバーライドさせることで、アプリケーションに制御を渡す）を越えて、あたらしい可能性とコードとしてのシンプルさを両立させている例です。ほとんどの属性を public にしていますし、主要クラスはたった３つ。HTMLに限って問題を解決することで、こんなに美しいコードになる。決して他人が簡単には到達できない設計に見えました。属性やメソッドの名前付けも単刀直入でうまく読めます。class Parse の中に more と parts という同じParse型の public 属性を持たせて、そこにコンストラクタで table を含む HTML をパースして入れてしまいます。S式に分解しているような感じです。おかげで、
Parse last() { return more == null ? this : more.last() }
みたいな、Lispっぽいというか、そんな自然なコードがぽんぽん書ける。
Rails のような、問題を限定してシンプルさを獲得して、余りあるパワーを出すフレームワークが、Javaでもこんな風にできるんだ。。。。と驚きと、そして、こんな設計をする勇気が湧きました。
そして、最後には、普通APIというとリリース後に変更の影響がでるために、できるだけ public な部分を絞るのに対し、FITでは、ほとんどオープンにしていること。そして、それが、プログラミングという活動のソーシャル性と関わっていること（分かってくれる人には、そのまま提供したほうがよい）、それが Beauty を作り出していることへの指摘があります。
このコード、ぜひみなさんにも味わって欲しいなぁ。良いコード、良い設計とは何か（何だったか）、という問いをもう一度考えられると思います。
推奨リンク：