「Map」を使用すると「assertThat」メソッドがコンパイルに失敗するのはなぜですか

Java ジェネリック: を拡張します。 vs. メソッド シグネチャ

Java ジェネリックを使用すると、さまざまなデータ型を操作できるタイプセーフなコレクションとメソッドを作成できます。ジェネリックを使用する場合は、 を拡張します。 <と<

次の例を考えてみましょう:

Map<String, Class<? extends Serializable>> expected = null;
Map<String, Class<Date>> result = null;
assertThat(result, is(expected));<p>この例では、次のメッセージを含むコンパイル エラーが生成されます:</p>
<pre class="brush:php;toolbar:false">Error: cannot find symbol method assertThat(java.util.Map<java.lang.String,java.lang.Class<java.util.Date>>, org.hamcrest.Matcher<java.util.Map<java.lang.String,java.lang.Class<? extends java.io.Serializable>>>)

なぜこのバージョンはコンパイルに失敗しますか?

その理由は の使用にあります。 Matcher クラス内。元の形式では、assertThat には T の型と正確に一致する Matcher が必要です。ただし、この例では、String から Class は、キーの型が String で、値の型が Class 。結果マップには Class が含まれているため、Class の場合、コンパイラは Matcher が予期されるマップと互換性があることを保証できません。

assertThat を Matcher< に変更することの欠点は何ですか? extends T>?

assertThat を Matcher を拡張します。これにより、T のスーパータイプに一致する Matcher を渡すことができます。これは単純な変更のように見えるかもしれませんが、予期しない動作を引き起こす可能性があります。たとえば、文字列のリストに一致するマッチャーがある場合、オブジェクトのリストのマッチャーを期待するメソッドにそれを渡すことができます。この場合、Matcher は実際のパラメーターを正しく照合できず、不正確な結果が生じる可能性があります。

JUnit でassertThat メソッドをジェネリック化することに意味はありますか?

JUnit でのassertThat のジェネリック化は、型の安全性を確保し、予期される型と実際の型の間の不一致を防ぐことを目的としています。ただし、上で説明したように、慎重に使用しないと潜在的な問題が発生する可能性もあります。

推奨事項

• どちらかを決定するときは? T> を拡張します。 <と<メソッド シグネチャでは、次の点を考慮することが重要です。

Use を拡張します。メソッドで T のスーパータイプを渡す必要がある場合。 を使用します。メソッドが T の完全な型一致を必要とする場合。これらの推奨事項に従うことで、Java ジェネリックスを使用する際のコンパイル エラーを回避し、型の安全性を確保できます。

以上が「Map」を使用すると「assertThat」メソッドがコンパイルに失敗するのはなぜですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。