序章
私は Scala で書かれた API に取り組んでいます。API の関数に渡されるパラメーターとしてデータ転送オブジェクト (DTO) を使用します。DTO は、API のユーザーによってインスタンス化されます。
API は非常に抽象的/汎用的であるため、API が操作するオブジェクトの属性を指定したいと考えています。例:
case class Person(name: String, birthdate: Date)
「P」のインスタンスがPerson
API に渡されるとき、API は操作する「P」の属性を知る必要がありname
ますbirthdate
。
したがって、「P」自体のインスタンス、ある種の属性の宣言、および「P」のタイプに関する追加情報を含む DTO を設計する必要があります。
文字列ベースのアプローチ
1 つの方法は、String
s を使用して "P" の属性とそのタイプを指定することです。String
s は非常に軽量でよく知られているため、これは比較的単純です。パッケージ、型、およびメンバーの正式な表記法があるためString
、宣言はある程度構造化されます。一方、ユーザーが無効なsString
を渡す可能性があるため、宣言を検証する必要があります。String
の代わりに専用の型で属性を表す型を想像できますString
。これには、構造が増えるという利点があり、それらの型でさえ、有効なインスタンスのみが存在できるように設計されている可能性があります。
リフレクション API アプローチ
もちろん、リフレクション API が頭に浮かび、リフレクション API の型を使用して属性を宣言することを実験しています。残念ながら、scala 2.10.x リフレクション API は少し直感的ではありません。少し混乱を招く可能性のある名前、シンボル、ミラー、タイプ、タイプタグがあります。
基本的に、String
sを使用した属性宣言には 2 つの選択肢があります。
- リフレクション API の「名前」を使用した属性宣言
- リフレクション API の「シンボル」(特に TermSymbol) を使用した属性宣言
私が見る限り、この方法で行くと、DTO を構築する API のユーザーは、リフレクション API とその名前/シンボルを処理する必要があります。また、API の実装ではリフレクション API を使用する必要があります。そのため、リフレクション コードを使用する場所が 2 か所あり、ユーザーはリフレクション API について少なくとも少しの知識が必要です。
質問
ただし、これらのアプローチがどれほど重いかはわかりません。
- 名前やシンボルは構築するのに費用がかかりますか?
- リフレクション API は、高価な操作結果のキャッシュを行いますか、それとも注意する必要がありますか?
- 名前とシンボルは、ネットワーク経由で別の JVM に転送できますか?
- それらはシリアライズ可能ですか?
主な質問: scala リフレクション API 名またはシンボルは、転送オブジェクト内での使用に適していますか?
これをリフレクション API で行うのは複雑に思えます。どんなヒントでも大歓迎です。また、他の代替案に関するヒントも。
PS: 私の API は複雑で、リフレクション部分はかなり実験的な状態にあるため、まだ独自のコードは含めていません。後で役立つものをお届けできますように。