Combinatoric Interfaceとはどういう意味ですか？
私はショーン・ペアレントの この講演 を見ています。彼は次のように述べています：
同じセマンティクスに対して同じ構文を選択すると、コードの再利用が可能になり、組み合わせインターフェースを回避できます
「組み合わせインターフェース」とはどういう意味ですか？
例で説明できますか？
追伸これについてもっと考えると、m x n関数（つまり、型と操作の可能な組み合わせ）を記述する代わりに、n型と型に共通のセマンティクスを持つm操作がある場合（型に対して同じことを行います）、 mジェネリック演算のみを記述します。それはどういう意味ですか？
彼は組み合わせインターフェイス（ビデオのサウンドトラック）について言及しているため、スピーカーの用語は不幸で曖昧ですが、 combinatoric interfaceを書きました（ビデオのスライド）。
スピーカーは実際にはinterface combinatoricsを指し、より正確には- 組み合わせ爆発 、つまりmxnの組み合わせによって引き起こされるコードの急速な成長ポストスクリプトで非常に正しく見つけたmの可能性と比較して。だからあなたはそれを正しく理解した:-)
スピーカーはC++と標準ライブラリに言及しているので、 <algorithm> や <iterator> などのライブラリでのテンプレートの使用（ジェネリックのC++の方法）により、プログラマは単一のインターフェースと同じ構文を使用して単一のコードを記述します。これは、順方向または逆方向の反復を使用して、12種類のコンテナーに再利用できます。もちろん、これらすべてが幸いなことに、ライブラリの作成者は同じ構文が同じセマンティクスを提供することを保証したためです。インターフェースや構文が異なるさまざまなコンテナで同じセマンティクスが実現される場合、同じプログラマが自分のコードの24のバリエーションを記述する必要があります。したがって、明らかに、再利用は促進されません。
私はプレゼンテーション全体を見ていませんでしたが、スピーカーは、たとえばコピーコンストラクターなど、構文に関連付けられたセマンティクスを尊重する必要性をすぐに述べています。彼の例は手元にありませんが、よく知られている演算子構文を予想されるセマンティクスに準拠しない動作に関連付けるために演算子のオーバーロードを誤用するStackOverflowの例はたくさんあります。私のお気に入りの例は、副作用を実行するためのoperator+の（誤）使用であり、+操作によって変更されるべきではないオブジェクトを変更します。これにより、a+bはb+aと同じではなくなり、a+b+cについて話す必要がなくなります。
言及する価値があるかもしれませんが、セマンティクスと特定の構文の組み合わせは言語イディオムの起源にあります。したがって、構文とセマンティックの関係を誤用すると、組み合わせの爆発（インターフェース効果）が発生するだけでなく、誤解やバグ（予想外）が大量に発生する可能性があります。
それは何も意味しません、それは言葉の悪い選択です。 Combinatoricallityは測定可能なプロパティではありません。実際、Wordの組み合わせは存在しません。
Wordの組み合わせは存在します：
それらの配置に関係なく、より多くの要素から所定の数の要素を選択することに関する。
したがって、彼が意味すること（彼が与える例で判断される）は、私たちが独自の概念を構成するのではなく、確立された意味概念を使用する必要があるということです。
コレクションにNumberOfElementsという名前のプロパティを作成することもできますが、これはPOLA（最小の驚きの原則）に違反します。先行技術があるので、それを使用する必要があります。
コレクションにアクセスされた回数を示すプロパティCountをコレクションに実装できます。これは同じ理由で悪いでしょう。
Combinatorics は、簡単に言うと、組み合わせを作成することです。
たとえば、色と衣服を組み合わせたとします。
* Red, green, blue
* Hat, shirt, pants
全部で6つのオプション（3色+3種類の服タイプ）がありますが、合計9通りの組み合わせがあります。オプションの数が増えると、この格差は大きくなります。存在する組み合わせの量（color_count * clothing_type_count）オプションの量をすぐに超えます（color_count + clothing_type_count）。
これらすべてをテストしたいとします。機能自体に対して個別のテストを作成するほうがよいでしょう。
* Test for red
* Test for green
* Test for blue
* Test for hat
* Test for shirt
* Test for pants
9つの組み合わせ自体をテストする場合と比較して、合計6つのテストが必要になるためです。
* Test for blue hat
* Test for blue shirt
* Test for blue pants
* Test for green hat
* Test for green shirt
* Test for green pants
* Test for Red Hat
* Test for red shirt
* Test for red pants
問題をさらに悪化させて、新しい色（黄色）を追加するとします。機能を個別にテストする場合、新しいテストを1つ作成する必要があります。
* Test for yellow
しかし、組み合わせ自体のテストを作成していたとしたら、3倍の作業が必要になります。
* Test for yellow hat
* Test for yellow shirt
* Test for yellow pants
例を拡大すると、組み合わせのテストに関する問題がさらに悪化することがわかります。服の種類が100ある場合、機能自体ではなくすべての組み合わせをテストすると、新しい色を追加するのに100倍の作業が必要になります。
同じセマンティクスに対して同じ構文を選択すると、コードの再利用が可能になり、組み合わせインターフェースを回避できます
「赤シャツ」は、「赤」と「シャツ」の機能を分離したものではなく、組み合わせインターフェースの例です。