2

私がよく行う2つの場所でクラスの構造的な変更を処理するのは面倒なので:

class A {
  class C{}
  class B{}
  private B bChild;
  private C cChild;

  private Object[] structure() {
    return new Object[]{bChild, cChild};
  }

  public int hashCode() {
      Arrays.hashCode(structure());
  }

  public boolean equals(Object that) {
    //type check here
    return Arrays.equals(this.structure(), ((A)that).structure());
  }
}

プリミティブのボクシング以外に、このアプローチの何が悪いのでしょうか? 改善できますか？

4

3 に答える 3

0

これは、ライブラリ メソッドを再利用する賢い方法であり、一般的には良い考えです。しかし、過剰な割り当てと配列操作を大量に行うため、頻繁に使用されるメソッドでは非常に非効率的です。全体として、私はそのかわいいと思いますが、それはレビューに合格しません.

于 2013-10-24T04:29:16.637 に答える
-2

コードに慣れている人は、何が起こっているのかを理解するのが少し難しくなります。私の以前の誤った回答が示すように、個々のフィールドをリストするよりも「自明」ではありません。確かに、「等しい」は通常、渡された「オブジェクト」で実装されるため、議論の余地がありますが、入力は参照の等価性チェックの後にキャストされます。ここではそうではありません。

改善の 1 つは、配列を構造体メソッドで作成するのではなく、プライベート データ メンバーとして格納し、ボックス化を回避するためにメモリを少し犠牲にすることです。

于 2013-10-24T04:01:57.923 に答える