最近買った C# 系の本の中ではダントツでよい。巨大な API ライブラリを設計するときに気を付けることが具体的に書いてあって参考になる。
neuecc 氏が前書きを書いていて 2章が素晴らしいと書いてあったけどそのとおり2章が素晴らしかった。ここまででも十分におつりが来る感触はある。
以下の引用が面白かった人は購入する価値があると思います。.NET 開発者が API 設計で後悔しているところが読めるなんてそんなに知見に溢れた書籍はなかなかない。
特によかったところ
自分と同じようなユーザー向けに設計するのは簡単で、そうではない人向けに設計するのはとても難しいことです。正直に言うと、ドメインの専門家によって設計された、ドメインの専門家にしか使えないAPIが多すぎます。
1回の大規模なユーザビリティスタディの計画、設計、実施に多大な労力を費やすよりも、API開発プロセス全体で、より小さく、より範囲を絞ったスタディを何度も実施する方が、はるかに価値が高い
主流のシナリオのAPIで必要となる初期化を、最小限に抑えるように設計すべきです。理想的には、基本的なシナリオ用に設計された型を使い始めるには、既定のコンストラクター、または単一のパラメーターを持つコンストラクターのいずれかで済むようにすべきです。
フレームワーク設計原則
フレームワークは、使い方のシナリオのセットと、それらのシナリオを実装するコードサンプルから設計を始めなければならない。
単純なシナリオでは、フレームワークはドキュメントを必要とせずに使用可能でなければならない。
.NET 開発者が API 設計で後悔しているところ
この逆もまた真なりで、「ほとんど使用されない型が含まれる名前空間に、一般的に使用される型を入れてはならない」と言えるでしょう。StringBuilderは、私達が後になってSystem名前空間に含めておけばよかったと思ったものの例です。この型はSystem.Text名前空間にありますが、その名前空間にある他の型よりもはるかに高い頻度で使用されるうえ、それらの型とはあまり関係がありません。
私の「もし願いがかなうなら、やり直したいこと」トップ10のひとつは、System.Threading.Tasksにあります。私達は当初、CPUベースの並列処理に焦点を当ててこれらのAPIを設計したのですが、時がたつにつれて、その最も一般的な使い方は当初の時点よりもはるかに、I/Oベースの非同期処理に焦点を当てたものへと変わってしまいました。そして、私達が当初設定した既定値の一部は、前者の場合は非常に適切なものでしたが、後者にとっては有害なものになりました。
