価値があるのは、ほとんどのスクリプト言語 (Perl など) と非静的コンパイル時言語 (Pick など) が、ランタイム動的 String から (比較的任意の) オブジェクトへの自動変換をサポートしていることです。これは、型安全性を失うことなくJavaでも実現でき、動的キャストで悪事を行う他の言語のいくつかの厄介な副作用なしに、静的に型付けされた言語が提供する優れた機能を提供します。疑わしい計算を行う Perl の例:
print ++($foo = '99'); # prints '100'
print ++($foo = 'a0'); # prints 'a1'
Java では、これは、私が「クロスキャスティング」と呼ぶ方法を使用することで (IMHO) よりよく達成されます。クロスキャストでは、次の静的メソッドを介して動的に検出されるコンストラクターとメソッドの遅延読み込みキャッシュでリフレクションが使用されます。
Object fromString (String value, Class targetClass)
残念ながら、Class.cast() などの組み込み Java メソッドは、String から BigDecimal へ、または String から Integer へ、またはサポートするクラス階層がないその他の変換に対してこれを行いません。私にとっては、これを達成するための完全に動的な方法を提供することがポイントです。これについては、以前の参照が正しいアプローチではないと思います。すべての変換をコーディングする必要があります。簡単に言えば、実装は、合法/可能であれば文字列からキャストするだけです。
したがって、解決策は、次のいずれかのパブリック メンバーを探す単純なリフレクションです。
STRING_CLASS_ARRAY = (new Class[] {String.class});
a) メンバー member = targetClass.getMethod(method.getName(),STRING_CLASS_ARRAY); b) メンバー member = targetClass.getConstructor(STRING_CLASS_ARRAY);
すべてのプリミティブ (Integer、Long など) とすべての基本 (BigInteger、BigDecimal など)、さらには java.regex.Pattern もすべてこのアプローチでカバーされていることがわかります。私はこれを使用して、より厳密なチェックが必要な任意の文字列値の入力が大量にある本番プロジェクトで大きな成功を収めました。このアプローチでは、メソッドがない場合、またはメソッドが呼び出されたときに例外がスローされます (BigDecimal への非数値入力やパターンの不正な RegEx などの不正な値であるため)。ターゲット クラス固有のロジック。
これにはいくつかの欠点があります。
1) リフレクションをよく理解する必要があります (これは少し複雑で、初心者向けではありません)。2) 一部の Java クラスと実際にはサードパーティのライブラリは (驚くべきことに) 適切にコーディングされていません。つまり、単一の文字列引数を入力として取り、ターゲット クラスのインスタンスを返すメソッドがありますが、それはあなたが考えているものではありません... Integer クラスを考えてみましょう。
static Integer getInteger(String nm)
Determines the integer value of the system property with the specified name.
上記の方法は、プリミティブ int をラップするオブジェクトとしての整数とはまったく関係ありません。リフレクションはこれを、decode、valueof、constructor メンバーと比較して、String から誤って Integer を作成する可能性のある候補として見つけます。これらはすべて、実際には入力データを制御できないが、単に変換したい場合のほとんどの任意の String 変換に適しています。整数が可能かどうかを知っています。
上記の問題を解決するには、例外をスローするメソッドを探すことから始めることをお勧めします。そのようなオブジェクトのインスタンスを作成する無効な入力値は例外をスローする必要があるためです。残念ながら、例外がチェック済みとして宣言されているかどうかは、実装によって異なります。たとえば、Integer.valueOf(String) はチェック済みの NumberFormatException をスローしますが、リフレクション ルックアップ中に Pattern.compile() 例外は見つかりません。繰り返しますが、この動的な「クロスキャスト」アプローチの失敗ではなく、オブジェクト作成メソッドでの例外宣言の非常に非標準的な実装だと思います。
上記の実装方法について詳しく知りたい場合はお知らせください。ただし、このソリューションは、型安全性の良い部分を失うことなく、より柔軟で拡張性が高く、コードが少ないと思います。もちろん、常に「自分のデータを知る」ことが最善ですが、私たちの多くが気付いているように、私たちは管理されていないコンテンツの受信者に過ぎず、適切に使用するために最善を尽くさなければなりません.
乾杯。