質問に疑問...
あなたの質問「型はプロトコルを介して何を提供しますか?」私には厄介に思えます。タイプとプロトコルは垂直です。彼らはさまざまなことを説明しています。タイプ/レコードはデータの構造を定義し、プロトコルはいくつかの動作または機能の構造を定義します。そして、この質問が奇妙に思える理由の一部は、これらのことが相互に排他的ではないということです! 型にプロトコルを実装させることで、プロトコルが記述する動作/機能を型に与えることができます。実際、あなたのコンテキストから、あなたがプロトコルを使用していたことが明らかになったので、どのようにプロトコルを使用していたのか疑問に思う必要があります。私の推測レコードでそれらを使用してきた(またはおそらく具体化して)が、プロトコルと(定義)タイプを一緒に簡単に使用できるということです。
私には、あなたはここでリンゴとオレンジを比較したようです. わかりやすくするために、リンゴとリンゴ、オレンジとオレンジをいくつかの異なる質問で比較してみましょう。
プロトコルはどのような問題を解決し、代替手段とそれぞれの長所/短所は何ですか?
プロトコルを使用すると、さまざまな型でさまざまな方法で動作する関数を定義できます。これを行う他の唯一の方法は、マルチメソッドと単純な関数ロジックです。
- マルチメソッド: 非常に柔軟であることに価値があります。ディスパッチ関数として渡すことにより、タイプに基づいて動作をディスパッチでき
type
ますが、ディスパッチには他の任意の関数を使用することもできます。
- 内部関数ロジック: 関数定義の条件文の型を (もちろん) 手動でチェックして、異なる型が与えられた場合に異なる処理方法を決定することもできます。これは、マルチメソッド ディスパッチよりも原始的であり、拡張性も低くなります。単純な場合を除いて、マルチメソッドが優先されます。
プロトコルには、高度に最適化された JVM クラス/メソッド ディスパッチに基づいているため、パフォーマンスが大幅に向上するという利点があります。さらに、プロトコルは式の問題に対処するように設計されており(よく読んでください)、優れたモジュール式の拡張可能な API を作成するための非常に強力なツールとなっています。
(def) レコードまたは (def) 型の具体化の利点/欠点は何ですか?
data の構造を指定する方法については、いくつかのオプションを利用できます。
- (def)records: 「アプリケーション ドメイン情報を表す」のに適した型を生成します ( http://clojure.org/datatypesから; 読む価値があります)
- (def)types: 標準のコレクション型など、「実装/プログラミング ドメインのアーティファクト」を作成するための軽量型を生成します。
- reify: 1 つ以上のプロトコルを実装する匿名型で 1 回限りのオブジェクトを構築します。良い... プロトコルを実装する必要がある1回限りのもの
実際には、レコードは clojure のハッシュ マップのように動作しますが、プロトコルを実装して属性検索を高速化できるという追加の利点があります。便利なことに、 は を介して拡張可能のままassoc
ですが、この方法で追加された属性はコンパイルされたルックアップのパフォーマンスを共有しません。これが、これらの構成がアプリケーション ロジックの実装に便利な理由です。deftype を使用すると、余分なバゲージを実装しないため、実装/プログラミング ドメインの側面で有利であり、これらのケースでの使用がよりクリーンになります。