データ型: deftype、defrecord、reify

Clojure は抽象化の観点から記述されています。シーケンス、コレクション、呼び出し可能性などの抽象化があります。さらに、Clojure はこれらの抽象化の多くの実装を提供します。抽象化はホストインターフェースによって指定され、実装はホストクラスによって指定されます。これは言語のブートストラップには十分でしたが、Clojure に同様の抽象化および低レベルの実装機能が残されていませんでした。プロトコルとデータ型の機能は、ホストプラットフォームの機能との妥協なしに、抽象化とデータ構造定義のための強力で柔軟なメカニズムを追加します。

データ型機能 - deftype、defrecord、reify は、抽象化の実装を定義するメカニズムを提供し、reify の場合はそれらの実装のインスタンスを提供します。抽象化自体は、プロトコルまたはインターフェースによって定義されます。データ型は、ホストタイプ（deftype と defrecord の場合は名前付き、reify の場合は匿名）を提供し、いくつかの構造（deftype と defrecord の場合は明示的なフィールド、reify の場合は暗黙的なクロージャ）と、オプションで抽象メソッドの型内実装を提供します。それらは、比較的クリーンな方法で、ホストの最高パフォーマンスのプリミティブ表現とポリモーフィズムメカニズムへのアクセスをサポートします。注意: それらは単なるホストインパーレン構成ではありません。それらはホスト機能の限定されたサブセットのみをサポートし、多くの場合、ホスト自体よりも動的です。意図は、相互運用によって限定された範囲を超えることを余儀なくされない限り、プラットフォームで可能な限り高性能なデータ構造を取得するために Clojure を離れる必要がないということです。

deftype と defrecord は、指定されたフィールドのセットと、オプションで 1 つ以上のプロトコルやインターフェースのメソッドを持つ名前付きクラスのコンパイル済みバイトコードを動的に生成します。それらは動的でインタラクティブな開発に適しており、AOT コンパイルする必要はなく、単一のセッション中に再評価できます。それらは、名前付きフィールドを持つデータ構造を生成するという点で defstruct と似ていますが、defstruct とは次の点で異なります。

deftype と defrecord は、次の点で異なります。

ほとんどの OO プログラムのクラスは、実装/プログラミングドメインの成果物であるクラス（例：String やコレクションクラス、または Clojure の参照型）と、アプリケーションドメイン情報を表すクラス（例：Employee、PurchaseOrder など）の 2 つの明確なカテゴリに分類されます。アプリケーションドメイン情報にクラスを使用することの不幸な特徴は、情報がクラス固有のマイクロ言語の背後に隠されることです。たとえば、一見無害な employee.getName() でさえ、データへのカスタムインターフェースです。このようなクラスに情報を入れることは、すべての本が異なる言語で書かれているようなものです。もはや情報処理に対する一般的なアプローチを取ることはできません。これは、不必要な具体性の爆発と、再利用の不足につながります。

これが、Clojure が常にそのような情報をマップに入れることを推奨してきた理由であり、そのアドバイスはデータ型でも変わりません。defrecord を使用すると、汎用的に操作可能な情報に加えて、型駆動のポリモーフィズムとフィールドの構造的効率という追加のメリットが得られます。OTOH、ベクターのようなコレクションを定義するデータ型がマップのデフォルト実装を持つことは意味がないため、deftype はこのようなプログラミング構成を定義するのに適しています。

全体として、レコードはすべての情報伝達目的において structmap よりも優れており、そのような structmap を defrecord に移動する必要があります。structmap をプログラミング構成に使用しようとしているコードは多くはないと思われますが、もしそうであれば、deftype がはるかに適していることがわかるでしょう。

AOT コンパイルされた deftype/defrecord は、制限が禁止されていない場合、gen-class のユースケースの一部に適している場合があります。そのような場合、gen-class よりもパフォーマンスが向上します。

データ型とプロトコルは、ホスト構成要素との明確に定義された関係を持ち、Clojure の機能を Java プログラムに公開するのに最適な方法ですが、それらは主に相互運用構成要素ではありません。つまり、ホストのすべての OO メカニズムを完全に模倣したり、適応したりする努力はしていません。特に、次の意見を反映しています。

データ型とプロトコルを使用すると、Java 消費者に提供するクリーンでインターフェースベースの API を持つことになります。クリーンなインターフェースベースの Java API を扱う場合、データ型とプロトコルを使用して相互運用および拡張できます。 '悪い' Java API を使用している場合は、gen-class を使用する必要があります。この方法でのみ、Clojure プログラムの設計と実装に使用するプログラミング構成要素が、OO の偶発的な複雑さから解放されます。

deftype と defrecord が名前付きの型を定義するのに対し、reify は匿名型を定義すると同時に、その型のインスタンスを作成します。これは、1つ以上のプロトコルやインターフェースの使い捨ての実装が必要で、ローカルコンテキストを利用したい場合に役立ちます。この点で、そのユースケースは proxy や Java の匿名内部クラスに似ています。

reify のメソッド本体はレキシカルクロージャであり、周囲のローカルスコープを参照できます。reify は proxy と以下の点で異なります。

結果として、構築と呼び出しの両方において proxy よりも優れたパフォーマンスが得られます。制約が過度に厳しい場合を除き、すべてのケースで reify は proxy よりも推奨されます。

deftype、defrecord、definterface で作成された型は、Java 相互運用用の Java アノテーションを含むクラスを出力できます。アノテーションは、以下のようにメタデータとして記述されます。

例