3

この投稿では、インターフェイスと匿名クラスを使用するソリューションを提案しました。ただし、実装する必要があるのはhashCodeandequalsメソッドです。

equalsただし、インターフェイスを実装する匿名クラスには実装が難しいことがわかりました。その例では、インターフェースはPair<L,R>であり、ファクトリメソッドPairs.makePairはその匿名実装を返します。実装を追加したとequalsします。ユーザーは別のコードを使用して独自のPair<L,R>クラスを実装できるequalsため、呼び出しでuserobj.equals(makepairobj)コードが入力されmakepairobj.equals(userobj)、私のコードが入力されます。私は彼らのコードを制御できないので、対称であることを確認するのは難しいequalsです。これは、適切な実装に必要です。

この問題は他の場合にもよくあることだと思いますが、この問題が一般的にどのように対処されているのか知りたいのですが。

編集：通常のクラスでは、の実装はequalsパラメータタイプをチェックして、それがそれ自体と同じであることを確認します。これにより、オブジェクトを比較するために実装コードのみが呼び出されることが保証されます。ただし、匿名クラスには名前がなく、タイプを.で確認することはできませんinstanceof。私にできることは、それが実装インターフェース/クラスのインスタンスであることを確認することです。これは、上記のシナリオを防ぐのに十分ではありません。

4

3 に答える 3

1

this.getClass()（またはのいずれか==を使用しisAssignableFrom()て）タイプを比較できます。

編集

のように：

public boolean equals(Object obj) {
    if (getClass() == obj.getClass()) {
        // do whatever
    }
    return false;
}
于 2012-11-09T03:55:21.037 に答える
1

通常、このようなインターフェイスを作成する場合は、実装クラスが実装equalsし、hashCode何らかの規則に従う必要があります。たとえば、java.util.Listインターフェイスを見ると、リストが同じ長さで同じ順序の要素が等しい場合はリストが等しい必要がありhashCode、要素のハッシュコードに基づいて計算するための式が指定されています。

したがって、「等しいが対称であることを確認するのは難しい」ということは問題ではないはずです。

于 2012-11-09T04:08:54.563 に答える
1

あなたが遭遇した問題は、匿名クラスがこれを実装するための間違った方法であるという兆候です。

匿名クラスは、インターフェイスを実装したり、クラスを拡張したりするための簡単な方法です。これは純粋にシンタックスシュガーであり、追加の機能やその他の利点はありません。それらは（おそらく誤って）コードをより単純で読みやすくすることを目的としていました。匿名クラスが代わりにコードを複雑にする場合は、それを使用しないでください。

以前は匿名クラスに適していた多くのケースが、ラムダによってより適切に処理されるようになりました。クラスに2つまたは3つのメソッドがある場合、それを匿名クラスに入れようとすると、コードが読みにくくなります。とにかくそれは内部クラスでなければなりません。

于 2016-08-10T15:26:06.077 に答える