.NETのクラスライブラリ設計 改訂新版 (マイクロソフト関連書) | Krzysztof Cwalina、Jeremy Barton、Brad Abrams, 猪股 健太郎、河合 宜文 (監訳), 藤原 雄介 |本 | 通販 | Amazon をここ2、3ヶ月ほどかけて一応読み終わったので、その時に考えたりしたことのまとめのその1です。
本書は、.NETのフレームワークを開発する際に推奨および、考慮や非推奨するべき内容についてDO/CONSIDER/DO NOT/AVOIDの4種類のラベルで整理したガイドラインを羅列しています。 なので、ガイドラインの羅列で読んでいて多少単調に感じたりする部分もありますが、背景情報や根拠なども記載されているので勉強になる内容も多くありました。 僕は普段はGoやTypeScriptを使ってプログラムを書いているので.NET以外の言語のライブラリに対してガイドラインを適用できるのかという視点でも読んでいました。
本書を読んでいて一番強く感じたことはライブラリの設計のガイドラインの多くが一般性や利用のしやすさに注意が割かれていることでした。 .NETのライブラリは全てC#、F#、Visual Basicの3つの言語から共通して使われうるためです。
使いやすさを担保するための手法として、他のサンプルコードを書いて実際に利用される状況を用意してから実装を行うことを推奨していました。具体的には、30分ドッグフーディングしてみてライブラリを使った動くコードが書けないならライブラリの設計が直感的でないや要求されるシナリオにあっていないので設計を考え直すべきのように具体的な時間とともに書かれている点が面白い。
このシナリオベースで実装を進めている証拠として、.NETのライブラリのドキュメントはサンプルコードが非常に多く掲載されています。
learn.microsoft.com
わかりやすい例として本書の中でも引用がされていた StopWatch クラスのドキュメントを載せましたが、他のクラスのドキュメントでも同様にサンプルコードが多く書かれています。
なので、基本的にはどのクラスでもサンプルコードをそのままコピーするだけで使い方が何となくわかるようになっています。
一般的なシナリオと応用的なシナリオでクラスやメソッドを分けて実装しようというとも書かれていた。
具体的には、一般用途用にDoShomething()を応用的な細かい制御をするためにDoSomthingUnSafe() や DoSomethingRaw() のようなメソッドを定義したり、Something クラスのフィールドとして、SomethingCore クラスを持って細かな制御は SomethingCore クラスに分離するようなこと。
実例がすぐには出てこないが、裏で複雑なことをやっているライブラリやフレームワークでは比較的よく使われている設計だと思う。
また、オブジェクトのStringメソッドで出力される文字列は開発者向けのメッセージに最適化することで、Console.log などで開発者がデバッグしたときに不具合の原因を調査しやすくし、アプリのユーザに見せる文字列は別にSomethingMessage()`のような専用のメソッドを用意すべしというガイドラインもあった。
これは、他の言語でも有用だと思う。
例えば、Go言語ならStringerインターフェースで実装して出力する文字列は開発者向けに最適化して、ユーザにオブジェクトの中身を文字列として見せる必要があるなら別のメソッドを定義すべしとなるのだろう。
近いうちにその2を書くつもりです。
