ジェネリックプログラミング

C++八冊目。

Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)

内容はかなりマニアック。特に、終わりの方の章は、問題のわりに仕組みが大掛かりになりすぎていると感じるところもある。でも、説明は非常に親切。それぞれ問題の背景から述べられており大変興味深く読めた。

特に面白かったところ。

1章。ポリシーを基にしたクラスデザイン。オブジェクト指向では、インタフェース同士が静的に結合して実装は動的に結合というのが基本。しかし、C++テンプレートを活用したジェネリックプログラミングでは、ポリシーで規定された実装を静的に結合させることができる。したがって、実行時のオーバーヘッドがまったく発生しない。

3章。タイプリスト、メタプログラミング。何かすごいことができそうな気はするのだが、今の時点では良くわからん。

6章。シングルトンの実装。僕がC++で困っていることの一つ。Javaのときは、僕はすべての自作インタフェースに、NULLオブジェクト（もしくはデフォルトオブジェクト）のstaticフィールドを用意していた。こんな感じ。

/**
* 自分が作ったインタフェースは, すべてこういう形をしている.
*/
interface IHoge {
　/**
　 * メソッド1.
　 */
　public void method1();
　/**
　 * メソッド2.
　 */
　public void mehtod2();
　/**
　 * NULLオブジェクトかどうか.
　 */
　public boolean isNull();
　/**
　 * NULLオブジェクト.
　 * 何もしない, デフォルトの振る舞いをする, デフォルト値を返す
　 * といったデフォルト実装を表す.
　 */
　public static final IHoge NULL = new IHoge() {
　　public void mehtod1() {
　　}
　　public void mehtod2() {
　　}
　　public boolean isNull() {
　　　return true;
　　}
　};
}

これが自分の中で生まれながらに身についていた必勝不敗の形だった。C++ではこれをやるとなったらどうすれば良いのだろうか。staticとかシングルトンの実装のし易さがJavaと微妙に異なるので困る。

8章。スマートポインタについて。スマートポインタが有効かどうかを判定するCheckingポリシーというのがあった。これをもっと充実させたら「完璧なスマートポインタ」というものが作れるかもしれない！これについては、また考えていきたい。

10章。ビジターパターンの実装。個人的には、ビジターパターンの導入の説明に興味をひかれた。

普通にオブジェクト指向で設計した場合、各コンポーネント郡は、インタフェースを通して、可能な限り疎な関係で結合されるように設計される。これにより、各コンポーネントの役割が明確になり、変更が容易になる。

しかし、ビジターパターンはこの思想の逆を行く。ビジターパターンが向いている状況というのは、クラス郡の変更は滅多にないが、それらの間のインタフェースが不安定というケースだ。

今まで僕は、直感にしたがって、ビジターパターンを設計指針の候補から外していた。でも、この説明を見ると、もしかしたら、分散システムの設計に使えるかもしれないと思う（もちろん細心の注意は必要だが）。というのも、分散システムというのは、登場人物はそんなに多くはない。サーバ、クライアント、その他、中間ノード、といったくらいだ。それよりも、それらの間の処理内容の方が安定していないことの方が多い。