.equals（）を生成するときにinstanceofよりgetClass（）を優先する理由はありますか？

私は生成するEclipseを使用している.equals()と.hashCode()し、「タイプを比較するために使用『のinstanceof』」ラベルされたオプションがあります。デフォルトでは、このオプションはオフになっており、.getClass()タイプの比較に使用されます。私は好むべきで何らかの理由がある.getClass()以上はinstanceof？

使用せずにinstanceof：

if (obj == null)
  return false;
if (getClass() != obj.getClass())
  return false;

使用instanceof：

if (obj == null)
  return false;
if (!(obj instanceof MyClass))
  return false;

私は通常、instanceofオプションをチェックしてから、「if (obj == null)」チェックを外します。（nullオブジェクトは常に失敗するため、冗長instanceofです。）悪い考えである理由はありますか？

を使用する場合instanceof、equals実装をfinal行うと、メソッドの対称コントラクトが保持されますx.equals(y) == y.equals(x)。final制限的と思われる場合は、オブジェクトの等価性の概念を注意深く調べて、オーバーライドする実装がObjectクラスによって確立されたコントラクトを完全に維持していることを確認してください。

Josh Blochはあなたのアプローチを支持しています：

私がこのinstanceofアプローチを支持する理由は、このアプローチを使用する場合、getClassオブジェクトは同じクラスの他のオブジェクトと同じランタイム型であるという制限があるためです。クラスを拡張し、それにいくつかの無害なメソッドを追加する場合は、サブクラスのオブジェクトがスーパークラスのオブジェクトと等しいかどうかを確認します。オブジェクトがすべての重要な面で等しい場合でも、彼らは等しくないという驚くべき答え。実際、これはLiskov置換原理の厳密な解釈に違反しており、非常に驚くべき動作につながる可能性があります。Javaでは、ほとんどのコレクション（HashTableなど）は、equalsメソッドに基づいています。スーパークラスのメンバーをハッシュテーブルにキーとして配置し、サブクラスインスタンスを使用して検索すると、それらは等しくないため、見つかりません。

このSOの回答も参照してください。

効果的なJavaの第3章でもこれについて説明しています。

アンジェリカランガーズシークレットオブイコールズは、Josh BlochやBarbara Liskovを含むいくつかのよく知られた例について長く詳細に議論し、それらのほとんどでいくつかの問題を発見しています。彼女はまたinstanceofvsに入りgetClassます。それからの引用

結論

equals（）の実装の任意に選択された4つの例を分析したら、何を結論付けますか？

まず第一に、equals（）の実装で型の一致のチェックを実行するには、2つの実質的に異なる方法があります。クラスでは、instanceof演算子を使用してスーパークラスオブジェクトとサブクラスオブジェクトを混合型で比較できます。または、クラスでgetClass（）テストを使用して、異なる型のオブジェクトを不等として扱うことができます。上記の例は、getClass（）を使用したequals（）の実装が、instanceofを使用した実装よりも一般的に堅牢であることを示しています。

instanceofテストは、最終クラス、または少なくともメソッドequals（）がスーパークラスでfinalである場合にのみ正しいです。後者は、サブクラスがスーパークラスの状態を拡張する必要はなく、一時的なフィールドや静的フィールドなど、オブジェクトの状態や動作に関係のない機能やフィールドのみを追加できることを本質的に意味します。

一方、getClass（）テストを使用した実装は、常にequals（）規約に準拠しています。それらは正しく、堅牢です。ただし、これらは、instanceofテストを使用する実装とは意味的に非常に異なります。getClass（）を使用した実装では、サブクラスがフィールドを追加せず、equals（）をオーバーライドしたくない場合でも、サブクラスとスーパークラスのオブジェクトを比較できません。そのような「自明な」クラス拡張は、たとえば、まさに「自明な」目的のために定義されたサブクラスにdebug-printメソッドを追加することになります。スーパークラスがgetClass（）チェックによる混合型の比較を禁止している場合、自明な拡張はそのスーパークラスに匹敵しません。これが問題であるかどうかは、クラスのセマンティクスと拡張の目的に完全に依存します。

使用する理由getClassは、equalsコントラクトの対称性を確保するためです。イコールのJavaDocsから：

これは対称です。null以外の参照値xおよびyについて、x.equals（y）は、y.equals（x）がtrueを返す場合にのみtrueを返します。

instanceofを使用すると、対称にならない可能性があります。例を考えてみましょう：犬は動物を拡張します。動物のはequalsありませんinstanceof動物のチェックを。Dog's equalsはDogのinstanceofチェックを行います。動物aと犬dを与える（他のフィールドも同じ）：

a.equals(d) --> true
d.equals(a) --> false

これは対称プロパティに違反しています。

イコールの規約を厳密に守るには、対称性を確保する必要があるため、クラスは同じである必要があります。

これは宗教的な議論のようなものです。どちらのアプローチにも問題があります。

• instanceofを使用すると、重要なメンバーをサブクラスに追加できません。
• getClassを使用すると、Liskov置換の原則に違反します。

Blochには、Effective Java Second Editionに関連する別のアドバイスがあります。

• 項目17：継承のための設計と文書化、またはそれの禁止

私が間違っている場合は修正してください。ただし、インスタンスが比較対象のクラスのサブクラスではないことを確認したい場合は、getClass（）が役立ちます。そのような状況でinstanceofを使用した場合、次の理由でそれを知ることができません。

class A { }

class B extends A { }

Object oA = new A();
Object oB = new B();

oA instanceof A => true
oA instanceof B => false
oB instanceof A => true // <================ HERE
oB instanceof B => true

oA.getClass().equals(A.class) => true
oA.getClass().equals(B.class) => false
oB.getClass().equals(A.class) => false // <===============HERE
oB.getClass().equals(B.class) => true

そのクラスのみが一致することを確認したい場合は、を使用しますgetClass() ==。サブクラスを一致させたい場合instanceofは、が必要です。

また、instanceofはnullとは一致しませんが、nullと比較しても安全です。したがって、nullチェックする必要はありません。

if ( ! (obj instanceof MyClass) ) { return false; }

特定のクラスのサブクラスがその親と等しいかどうかを検討するかどうかによって異なります。

class LastName
{
(...)
}


class FamilyName
extends LastName
{
(..)
}

ここでは、LastNameをFamilyNameと比較するため、「instanceof」を使用します。

class Organism
{
}

class Gorilla extends Organism
{
}

ここでは、2つのインスタンスは同等ではないとクラスがすでに言っているため、「getClass」を使用します。

instanceofは、同じクラスまたはそのサブクラスのインスタンスに対して機能します

これを使用して、オブジェクトがクラスのインスタンス、サブクラスのインスタンス、または特定のインターフェースを実装するクラスのインスタンスであるかどうかをテストできます。

ArryaListとRoleListはどちらもインスタンスのリストです

ながら

getClass（）== o.getClass（）は、両方のオブジェクト（thisとo）がまったく同じクラスに属している場合にのみtrueになります。

したがって、比較する必要があるものに応じて、どちらか一方を使用できます。

ロジックが「1つのオブジェクトが他のオブジェクトと等しいのは、それらが両方とも同じクラスである場合のみ」である場合、ほとんどの場合、「等しい」を使用する必要があります。

どちらの方法にも問題があります。

サブクラスがIDを変更する場合、実際のクラスを比較する必要があります。それ以外の場合は、対称プロパティに違反します。たとえば、異なるタイプのはPerson、たとえ同じ名前であっても、同等であると見なすべきではありません。

ただし、一部のサブクラスはIDを変更せず、これらを使用する必要がありますinstanceof。たとえば、不変のShapeオブジェクトの束がある場合、Rectangle長さと幅が1のa はunitと等しくなければなりませんSquare。

実際には、前者のケースが真実である可能性が高いと思います。通常、サブクラス化はあなたのアイデンティティの基本的な部分であり、あなたが1つの小さなことを行うことができることはあなたを平等にしないことを除いて、あなたの親とまったく同じです。

実際にinstanceofは、オブジェクトが階層に属しているかどうかをチェックします。例：CarオブジェクトはVehicalクラスに属しています。したがって、「Vehicalの新しいCar（）インスタンス」はtrueを返します。また、 "new Car（）。getClass（）。equals（Vehical.class）"はfalseを返しますが、CarオブジェクトはVehicalクラスに属していますが、別のタイプに分類されています。