要求事項をまとめてコンセプトにする方法の決定と、各アルゴリズムで使用するコンセプトを決定する過程は、恐らくジェネリック・ライブラリを構築する上で最も困難な(けれども最も重要な) 段階である。 この過程を勤しむ際に使用する指針を、要求事項最小化原理と呼んでいる。
要求事項最小化原理：より再利用しやすくなるように、コンポーネントの入力パラメータに対する要求事項を最小限にすること。
この文言には、相反する問題が含まれている。 定義によれば、コンポーネントは課されたタスクを遂行するために、入力パラメータを使用しなければならない(ここで「コンポーネント」とは、関数テンプレートもしくはクラス・テンプレートを意味する)。 その上で、入力に関する仮定を最小に限定する(最小必要条件)ような方法でコンポーネントを実装することが求められる。
抽象 という従来からある概念は、最小要求事項というアイディアに直接結び付いている。 入力が抽象的であるほど、要求事項は少なくなる。 よって、コンセプトは、C++ テンプレート・プログラミングにおけるジェネリックな抽象データ型の単純な具象化である。
ある問題領域に対するコンセプトを設計する場合、すなわち、コンポーネントへの入力に関する要求事項を表現するためには、その目的を念頭においておくことが重要である。 要求事項最小化原理に関しては、これは、コンセプトの極小化を意味する。
(訳注1)
コンセプトにおける極小性は、表現されている問題領域の基礎的なセマンティックスに関連したプロパティである。 基本コンテナの問題領域では、単一方向へのトラバースを必要とすることは、両方向へ必要とするより小さな要求事項である (つまりは ForwardIterator と BidirectionalIterator の相違である) 。 セマンティクスの違いは、前方イテレータを有する具象データ型の集合と、双方向イテレータを持つ集合との間にある差異から、容易に見い出すことができる。 例えば、単方向リンク・リストは、双方向イテレータではなく前方イテレータを有するデータ構造の集合に含まれるだろう。 さらに、前方イテレータだけを使用して実装することができるアルゴリズムの集合は、双方向イテレータ無しにはインプリメントできないアルゴリズム集合とは全く重なることがない。 このために、要求事項の一群をある程度きめ細かくコンセプト別に分類することが重要である。 例えば、イテレータに対する要求事項は、STL における６つのイテレータ・コンセプト(自明、出力、入力、前方、双方向、ランダムアクセス)に分類される。
ここには、重要な論点について記したパラグラフがありましたが、標準との整合性の理由からコメントアウトされています。コメントアウトされた内容を、以下に翻訳引用します：
以下の文章は、LessThanComparable の変更された標準定義およびニーズと一致しない。-Jeremy
しかし、コンセプトの極小化が、コンセプト内で有効式の数を単純に減少させることに直結しないことは重要な注意点である。
例えば、std::stable_sort()関数は、値型のイテレータが LessThanComparable を満たすことを必要とするが、このコンセプトは operator<() だけでなく、operator>、operator<=()、operator>=() を含んでいる。
std::stable_sort() は operator<() のみを使用することが判明している。
そうなると、疑問が生じる：
std::stable_sort() の特殊化は、LessThanComparable コンセプトに基づくべきなのか、あるいはただoperator<() のみを必要とするコンセプトに基づくべきなのだろうか。
operator<() から他の演算子をすべて自明な形で実装できるので、LessThanComparable を用いても実際には要求事項最小化原理に触れてはいない、とまずは云うことができよう。
ここで「自明」が意味するのは、一行のコードと実行時に課される一定のコストに過ぎない。
とはいえ、より根源的に言えば、全ての比較演算子 (<、>、<=、>=) は (数学的な感覚において) 概念的に等価であるから、LessThanComparable を用いたとしても要求事項最小化原理を犯すことにはならない。
概念的に等価な有効式を加えたとしても、セマンティクスの面からすれば、新しいものはなにも加わっていない――ただ新しい構文だけである――ので、要求事項最小化原理の侵害にはあたらない。
こういった構文の追加は再利用性を高めるのだ。
例えば、結局のところ比較演算子は等価であるから、std::stable_sort() の管理者がいつか operator<() の代わりに operator>() を使用するよう実装を変更するかもしれない。
要求事項は公開インタフェースの一部であるから、そのような変更は潜在的にクライアント・コードを破壊しかねない。
代わりに、LessThanComparable がstd::stable_sort()の要求事項であれば、管理者がその仕事をこなす際に、妥当な程度の柔軟性を与えられることになる。
Copyright © 2000 Jeremy Siek(jsiek@osl.iu.edu) Andrew Lumsdaine(lums@osl.iu.edu)