Microsoft の人々が .NET のライブラリを作る際にこんなことを考えて作ったんですよ、という "Framework Design Guidelines" (邦訳も『.NETのクラスライブリ設計』という名前で出ている) という本があり、それをずっと読んでいる。やっと半分まで来たんだけど、ここまででも十分に良い本だった。
最初 (1.1.4 にある Chris Sells の注) から
Please don't innovate in library design. Make the API to your library as boring as possible. You want the functionality to be interesting, not the API.
と、しびれる。ほんとねー、おれは最近の DSL ブームはねえ、ってそれはいまはいいや。
本自体は "Property Design" みたいな個々の細かな話題について、議論があって、まとめで DO/CONSIDER/DO NOT/AVOID のどれかではじまる文章の箇条書きで指針が示される、というかたちになっている。フレームワークといっても、論調はふつうのプログラミングの指針と大きな差異はない。ただ 2.2.1 では
The problem is that most design methodologies (including most commonly used object-oriented design methodologies) are optimized for the maintainability of the resulting implementation, not for usability of the resulting API.
なので、そういうのは、でかいフレームワークの API 層の design には向かないよ、と主張されている。
.NET 固有のこともいくつかでてくるけど Java, Scala みたいな親戚や、Perl, Python, Ruby みたいなスクリプト言語でも、クラスがあってインターフェースがあって例外があって、みたいなところで共通部分は多い。そういう言語をつかってプログラミングをしているひとなら、学べる部分はかなりあると思う。私は最近スクリプト言語を書くことが多いので、感心したり、自分のつかっている言語の語彙の貧弱さを残念がったりしている。
注釈
ちょっと珍しいのが記名の注釈が多いところで、地の文での議論に対して "Krzysztof Cwalina" みたいな名前付きで、補ったり、反論したり、注釈どうしで盛り上がったりするところがたまにある。
例えば、3.5 Names of Class, Structs, and Interfaces では Krzysztof Cwalina の「インターフェースに "I" がついてるのがあるけど、あれは歴史的事情で、いま考えるとやんなくてよかったよ。」という注に「COM とか Java からきたんだよね "I" つけるの。慣れてる人も多いし。」「個人的には好きだよ。」「ハンガリアン記法の応用だよね。」「System._AppDomain はまずったわー。AppDomain が implements してるんだから IAppDomain にすべき。」「HttpSessionState も IHttpSessionState あるとおもうと違うんだよねえ。」と、なんていうんですか、bikeshed で社内 Wiki 炎上みたいな、ガイドラインとしては見解統一しようよと思いつつも、読む分には面白い。
4.3 Choosing Between Class and Interface でも Chris Anderson が「.NET やったときは、なんというか、COM の複雑さ厳格さに反動がきててねえ、インターフェースも GUID も variant もIDL も、全部だめなものにみえててさ。いまならもうちょっと中立的な目でみれると思うんだけど。」と突然の告白がはじまっていて笑ってしまう。
まとめ
というわけで "Framework Design Guidelines" (『.NETのクラスライブリ設計』) はおすすめだよという話でした。DVD の内容は Web からもダウンロード できます。