ポリシークラスってなんぞや？〜その２〜

1章 1.2 何でもやっちゃえインターフェースの失敗（後半）

異なった設計ごとに小さなクラスを用意してみたら？の失敗

例えば、スマートポインタの場合、SingleThreadSmartPtr、MultiThreadedSmartPtr、RefCountedSmartPtr、RefLinkedSmartPtrといって一連の設計が考えられます。
しかし、これの問題点として、様々な設計によって爆発的な組み合わせが発生します。
例えば、上記の4つがあるということは、当然、SingleThreadRefCountedSmartPtrが考えられるわけだし、MultiThreadedRefLinkedSmartPtrなんてのも考えられます。
全部の組み合わせについてクラスを用意してたら莫大な量になりますし、ちょっと参照カウンタ部分の処理を修正しようと思ったら、RefCountedSmartPtrとSingleThreadSmartPtrとどちらにも修正を加えなくてはなりません。

著者は、ライブラリは設計を支援するような構造を持つことが望ましいと考えておられるようです。
また、設計指向のライブラリは、定義済みの制約ではなく、ユーザーの考え出した設計自身の制約を強制するように支援しなくてはならない、と書かれています。

これがどういう意味か、正直、よくわからないのですが、これは、

悪い

「SingleThreadSmartPtrや、SingleThreadRefCountedSmartPtrといったすでにライブラリ側にあるスマートポインタしか使えない」という制約のあるライブラリは良くない。

良い

「SingleThreadedでRefCountedといった既存のクラスの組み合わせのポインタ、もしくは、SingleThreadedで独自RefCountedといったユーザーの設計の入ったしたポインタ。」
というように、ユーザーに設計の選択権がある。
しかし、クラスの組み合わせ方や、独自部分の設計いかんによってはコンパイルエラーになる。
そんなライブラリが良い。

という意味だろかと推察しています。
ちょっとよくわからじ。です。