Bất kỳ lý do nào để thích getClass () hơn thể hiện khi tạo .equals ()?

Tôi đang sử dụng Eclipse để tạo .equals()và .hashCode(), và có một tùy chọn có nhãn "Sử dụng 'instanceof' để so sánh các loại". Mặc định là tùy chọn này được bỏ chọn và sử dụng .getClass()để so sánh các loại. Có bất kỳ lý do tôi nên thích .getClass()hơn instanceof?

Không sử dụng instanceof:

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

Sử dụng instanceof:

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

Tôi thường kiểm tra instanceoftùy chọn, sau đó đi vào và loại bỏ if (obj == null)kiểm tra "". (Nó là dư thừa vì các đối tượng null sẽ luôn luôn thất bại instanceof.) Có lý do nào đó là một ý tưởng tồi không?

Nếu bạn sử dụng instanceof, equalsthực hiện việc triển khai của bạn finalsẽ duy trì hợp đồng đối xứng của phương thức : x.equals(y) == y.equals(x). Nếu finalcó vẻ hạn chế, hãy kiểm tra cẩn thận khái niệm tương đương đối tượng của bạn để đảm bảo rằng các triển khai ghi đè của bạn duy trì đầy đủ hợp đồng được thiết lập bởi Objectlớp.

Josh Bloch ủng hộ cách tiếp cận của bạn:

Lý do mà tôi ủng hộ instanceofcách tiếp cận là khi bạn sử dụng getClasscách tiếp cận, bạn có hạn chế rằng các đối tượng chỉ bằng với các đối tượng khác cùng lớp, cùng loại thời gian chạy. Nếu bạn mở rộng một lớp và thêm một vài phương thức vô hại vào nó, sau đó kiểm tra xem liệu một số đối tượng của lớp con có bằng với một đối tượng của siêu lớp hay không, ngay cả khi các đối tượng bằng nhau trong tất cả các khía cạnh quan trọng, bạn sẽ nhận được câu trả lời đáng ngạc nhiên rằng họ không bằng nhau. Trên thực tế, điều này vi phạm một cách giải thích chặt chẽ về nguyên tắc thay thế Liskov , và có thể dẫn đến hành vi rất đáng ngạc nhiên. Trong Java, nó đặc biệt quan trọng vì hầu hết các bộ sưu tập (HashTable, v.v.) dựa trên phương pháp đẳng thức. Nếu bạn đặt một thành viên của siêu lớp trong bảng băm làm khóa và sau đó tìm kiếm nó bằng một thể hiện của lớp con, bạn sẽ không tìm thấy nó, bởi vì chúng không bằng nhau.

Xem thêm câu trả lời SO này .

Chương 3 Java hiệu quả cũng đề cập đến điều này.

Angelika Langers Bí mật của sự bình đẳng được đưa vào đó với một cuộc thảo luận dài và chi tiết cho một vài ví dụ phổ biến và nổi tiếng, bao gồm Josh Bloch và Barbara Liskov, phát hiện ra một vài vấn đề trong hầu hết chúng. Cô cũng được vào instanceofvs getClass. Một số trích dẫn từ nó

Kết luận

Sau khi mổ xẻ bốn ví dụ được lựa chọn tùy ý về việc thực hiện bằng (), chúng ta kết luận điều gì?

Trước hết: có hai cách khác nhau để thực hiện kiểm tra đối sánh loại trong việc thực hiện bằng (). Một lớp có thể cho phép so sánh kiểu hỗn hợp giữa các đối tượng siêu và lớp con bằng toán tử thể hiện hoặc một lớp có thể coi các đối tượng thuộc loại khác là không bằng nhau bằng phép thử getClass (). Các ví dụ ở trên minh họa độc đáo rằng việc triển khai bằng () bằng cách sử dụng getClass () thường mạnh hơn so với các triển khai sử dụng instanceof.

Kiểm tra thể hiện chỉ đúng cho các lớp cuối cùng hoặc nếu ít nhất phương thức bằng () là cuối cùng trong một siêu lớp. Về cơ bản, hàm ý rằng không có lớp con nào phải mở rộng trạng thái của lớp cha, mà chỉ có thể thêm chức năng hoặc các trường không liên quan đến trạng thái và hành vi của đối tượng, chẳng hạn như trường tạm thời hoặc trường tĩnh.

Mặt khác, việc sử dụng thử nghiệm getClass () luôn tuân thủ hợp đồng bằng (); họ đúng và mạnh mẽ Tuy nhiên, chúng rất khác biệt về mặt ngữ nghĩa so với việc triển khai sử dụng thử nghiệm thể hiện. Việc triển khai bằng getClass () không cho phép so sánh giữa các đối tượng siêu lớp, ngay cả khi lớp con không thêm bất kỳ trường nào và thậm chí không muốn ghi đè bằng (). Ví dụ, một phần mở rộng lớp "tầm thường" như vậy sẽ là sự bổ sung của phương thức in gỡ lỗi trong một lớp con được xác định chính xác cho mục đích "tầm thường" này. Nếu siêu lớp cấm so sánh kiểu hỗn hợp thông qua kiểm tra getClass (), thì phần mở rộng tầm thường sẽ không thể so sánh với siêu lớp của nó. Đây có phải là một vấn đề hoàn toàn hay không phụ thuộc vào ngữ nghĩa của lớp học và mục đích của phần mở rộng.

Lý do để sử dụng getClasslà để đảm bảo tài sản đối xứng của equalshợp đồng. Từ JavaDocs bằng:

Đó là đối xứng: đối với mọi giá trị tham chiếu không null x và y, x.equals (y) sẽ trả về true khi và chỉ khi y.equals (x) trả về true.

Bằng cách sử dụng instanceof, có thể không đối xứng. Hãy xem xét ví dụ: Chó kéo dài Động vật. Động vật equalslàm một instanceofkiểm tra Thú. Chó equalslàm một instanceofkiểm tra của con chó. Cho Animal a và Dog d (với các trường khác giống nhau):

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

Điều này vi phạm tài sản đối xứng.

Để tuân thủ nghiêm ngặt hợp đồng của nhau, tính đối xứng phải được đảm bảo, và do đó, lớp cần phải giống nhau.

Đây là một cái gì đó của một cuộc tranh luận tôn giáo. Cả hai phương pháp đều có vấn đề của họ.

• Sử dụng thể hiện và bạn không bao giờ có thể thêm các thành viên quan trọng vào các lớp con.
• Sử dụng getClass và bạn vi phạm nguyên tắc thay thế Liskov.

Bloch có một lời khuyên khác có liên quan trong Ấn bản thứ hai hiệu quả của Java :

• Mục 17: Thiết kế và tài liệu để thừa kế hoặc cấm nó

Sửa lỗi cho tôi nếu tôi sai, nhưng getClass () sẽ hữu ích khi bạn muốn đảm bảo cá thể của bạn KHÔNG phải là một lớp con của lớp mà bạn đang so sánh. Nếu bạn sử dụng instanceof trong tình huống đó, bạn KHÔNG thể biết điều đó bởi vì:

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

Nếu bạn muốn đảm bảo chỉ có lớp đó sẽ phù hợp thì hãy sử dụng getClass() ==. Nếu bạn muốn phù hợp với các lớp con thì instanceofcần thiết.

Ngoài ra, instanceof sẽ không khớp với null nhưng an toàn để so sánh với null. Vì vậy, bạn không cần phải kiểm tra nó.

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

Nó phụ thuộc nếu bạn xem xét nếu một lớp con của một lớp nhất định bằng với lớp cha của nó.

class LastName
{
(...)
}


class FamilyName
extends LastName
{
(..)
}

Ở đây tôi sẽ sử dụng 'instanceof', vì tôi muốn LastName được so sánh với FamilyName

class Organism
{
}

class Gorilla extends Organism
{
}

Ở đây tôi sẽ sử dụng 'getClass', vì lớp đã nói rằng hai trường hợp này không tương đương nhau.

instanceof hoạt động cho các bản năng của cùng một lớp hoặc các lớp con của nó

Bạn có thể sử dụng nó để kiểm tra xem một đối tượng là một thể hiện của một lớp, một thể hiện của một lớp con hay một thể hiện của một lớp thực hiện một giao diện cụ thể.

ArryaList và RoleList đều là thể hiện Danh sách

Trong khi

getClass () == o.getClass () sẽ chỉ đúng nếu cả hai đối tượng (this và o) thuộc cùng một lớp.

Vì vậy, tùy thuộc vào những gì bạn cần so sánh, bạn có thể sử dụng cái này hay cái khác.

Nếu logic của bạn là: "Một đối tượng chỉ bằng nhau nếu cả hai cùng một lớp" thì bạn nên chọn "bằng", mà tôi nghĩ là hầu hết các trường hợp.

Cả hai phương pháp đều có vấn đề của họ.

Nếu lớp con thay đổi danh tính, thì bạn cần so sánh các lớp thực tế của chúng. Nếu không, bạn vi phạm tài sản đối xứng. Ví dụ, các loại khác nhau củaPerson s không nên được coi là tương đương, ngay cả khi chúng có cùng tên.

Tuy nhiên, một số lớp con không thay đổi danh tính và những thứ này cần sử dụng instanceof. Chẳng hạn, nếu chúng ta có một loạt các Shapeđối tượng bất biến , thì a Rectanglecó chiều dài và chiều rộng bằng 1 phải bằng đơn vị Square.

Trong thực tế, tôi nghĩ trường hợp trước có nhiều khả năng là sự thật. Thông thường, phân lớp là một phần cơ bản của danh tính của bạn và giống hệt cha mẹ của bạn ngoại trừ bạn có thể làm một việc nhỏ không khiến bạn trở nên bình đẳng.

Trên thực tế, hãy kiểm tra xem một đối tượng có thuộc phân cấp nào đó hay không. ví dụ: Đối tượng ô tô thuộc lớp Vehical. Vì vậy, "xe mới () của Vehical" trả về đúng. Và "Xe mới (). GetClass (). Bằng (Vehical. Class)" trả về sai, mặc dù đối tượng Xe thuộc lớp Vehical nhưng nó được phân loại thành một loại riêng biệt.