Tại sao không == so sánh giá trị chuỗi toán tử làm cho nó thành Java?

Mọi lập trình viên Java có thẩm quyền đều biết rằng bạn cần sử dụng String.equals () để so sánh một chuỗi, thay vì == vì == kiểm tra sự bằng nhau tham chiếu.

Khi tôi đang xử lý các chuỗi, hầu hết thời gian tôi đang kiểm tra sự bình đẳng giá trị hơn là sự bình đẳng tham chiếu. Đối với tôi, dường như sẽ trực quan hơn nếu ngôn ngữ cho phép so sánh các giá trị chuỗi bằng cách chỉ sử dụng ==.

Để so sánh, toán tử C = 's == kiểm tra sự bằng nhau về giá trị cho chuỗi s. Và nếu bạn thực sự cần thiết để kiểm tra sự bằng nhau tham chiếu, bạn có thể sử dụng String.ReferenceEquals.

Một điểm quan trọng khác là Chuỗi là bất biến, do đó không có hại gì khi thực hiện bằng cách cho phép tính năng này.

Có bất kỳ lý do cụ thể tại sao điều này không được triển khai trong Java không?

Tôi đoán đó chỉ là sự nhất quán, hay "nguyên tắc ít ngạc nhiên nhất". Chuỗi là một đối tượng, vì vậy sẽ rất ngạc nhiên nếu được đối xử khác với các đối tượng khác.

Vào thời điểm Java xuất hiện (~ 1995), chỉ có một thứ gì đó giống như Stringlà hoàn toàn xa xỉ đối với hầu hết các lập trình viên, những người đã quen với việc biểu diễn các chuỗi như các mảng kết thúc null. StringHành vi của bây giờ là những gì trước đây, và điều đó thật tốt; tinh tế thay đổi hành vi sau này có thể có tác dụng đáng ngạc nhiên, không mong muốn trong các chương trình làm việc.

Là một lưu ý phụ, bạn có thể sử dụng String.intern()để có được một đại diện chính tắc (đã được thực hiện) của chuỗi, sau đó có thể so sánh với ==. Thực tập cần một chút thời gian, nhưng sau đó, việc so sánh sẽ thực sự nhanh chóng.

Ngoài ra, không giống như một số câu trả lời gợi ý, nó không phải là về việc hỗ trợ quá tải toán tử . Các +nhà điều hành (nối) hoạt động trên Strings mặc dù Java không hỗ trợ khai thác quá tải; nó chỉ đơn giản được xử lý như một trường hợp đặc biệt trong trình biên dịch, giải quyết StringBuilder.append(). Tương tự, ==có thể đã được xử lý như một trường hợp đặc biệt.

Vậy thì tại sao lại kinh ngạc với trường hợp đặc biệt +mà không phải với ==? Bởi vì, +đơn giản là không biên dịch khi áp dụng cho các Stringđối tượng không phải là điều rõ ràng. Chênh lệch hành vi của ==sẽ được nhiều ít rõ ràng và do đó đáng kinh ngạc hơn khi nó chạm bạn.

James Gosling , người tạo ra Java, đã giải thích nó theo cách này vào tháng 7 năm 2000 :

Tôi đã bỏ quá tải toán tử như một lựa chọn khá cá nhân vì tôi đã thấy quá nhiều người lạm dụng nó trong C ++. Tôi đã dành rất nhiều thời gian trong năm đến sáu năm qua để khảo sát mọi người về tình trạng quá tải của nhà điều hành và điều đó thực sự hấp dẫn, bởi vì bạn khiến cộng đồng bị chia thành ba phần: Có lẽ khoảng 20 đến 30 phần trăm dân số nghĩ về việc quá tải nhà điều hành là sinh sản của quỷ; ai đó đã làm gì đó với tình trạng quá tải toán tử vừa thực sự đánh dấu họ, bởi vì họ đã sử dụng like + để chèn danh sách và nó làm cho cuộc sống thực sự, thực sự khó hiểu. Rất nhiều vấn đề đó xuất phát từ thực tế là chỉ có khoảng nửa tá toán tử mà bạn có thể quá tải một cách hợp lý, nhưng vẫn có hàng ngàn hoặc hàng triệu toán tử mà mọi người muốn xác định - vì vậy bạn phải chọn,

Tính nhất quán trong ngôn ngữ. Có một toán tử hoạt động khác nhau có thể gây ngạc nhiên cho các lập trình viên. Java không cho phép người dùng quá tải toán tử - do đó, đẳng thức tham chiếu là ý nghĩa hợp lý duy nhất cho ==giữa các đối tượng.

Trong Java:

• Giữa các kiểu số, ==so sánh đẳng thức số
• Giữa các kiểu boolean, ==so sánh đẳng thức boolean
• Giữa các đối tượng, ==so sánh danh tính tham chiếu
  • Sử dụng .equals(Object o)để so sánh các giá trị

Đó là nó. Quy tắc đơn giản và đơn giản để xác định những gì bạn muốn. Tất cả điều này được đề cập trong phần 15,21 của JLS . Nó bao gồm ba tiểu mục dễ hiểu, thực hiện và lý do.

Khi bạn cho phép quá tải== , hành vi chính xác không phải là thứ mà bạn có thể tìm đến JLS và đặt ngón tay lên một mặt hàng cụ thể và nói "đó là cách nó hoạt động", mã có thể trở nên khó hiểu. Hành vi chính xác của ==có thể gây ngạc nhiên cho người dùng. Mỗi khi bạn nhìn thấy nó, bạn phải quay lại và kiểm tra xem nó thực sự có nghĩa là gì.

Vì Java không cho phép quá tải các toán tử, nên người ta cần một cách để kiểm tra tính bằng giá trị mà bạn có thể ghi đè định nghĩa cơ sở. Vì vậy, nó đã được ủy thác bởi các lựa chọn thiết kế. ==trong Java kiểm tra số cho các kiểu số, đẳng thức boolean cho các kiểu boolean và đẳng thức tham chiếu cho mọi thứ khác (có thể ghi đè .equals(Object o)để làm bất cứ điều gì chúng muốn cho đẳng thức giá trị).

Đây không phải là vấn đề "có trường hợp sử dụng cho một hậu quả cụ thể của quyết định thiết kế này không" mà là "đây là một quyết định thiết kế để tạo điều kiện thuận lợi cho những điều khác, đây là hậu quả của nó."

Chuỗi thực tập , là một ví dụ như vậy về điều này. Theo JLS 3.10.5 , tất cả các chuỗi ký tự được thực hiện. Các chuỗi khác được thực tập nếu một người gọi .intern()chúng. Đó "foo" == "foo"là sự thật là kết quả của các quyết định thiết kế được thực hiện để giảm thiểu dung lượng bộ nhớ được sử dụng bởi các chuỗi ký tự. Ngoài ra, thực tập String là một cái gì đó ở cấp độ JVM có một chút tiếp xúc với người dùng, nhưng trong phần lớn các trường hợp, không phải là điều khiến lập trình viên quan tâm (và các trường hợp sử dụng cho lập trình viên không một cái gì đó cao trong danh sách cho các nhà thiết kế khi xem xét tính năng này).

Mọi người sẽ chỉ ra điều đó +và +=bị quá tải cho String. Tuy nhiên, đó không phải là ở đây và cũng không có. Trường hợp nếu ==có một giá trị bằng nhau có nghĩa là Chuỗi (và chỉ Chuỗi), thì người ta sẽ cần một phương thức khác (chỉ tồn tại trong Chuỗi) cho đẳng thức tham chiếu. Hơn nữa, điều này sẽ làm phức tạp các phương thức lấy Object và mong ==muốn hành xử theo một cách và .equals()hành xử khác yêu cầu người dùng xử lý đặc biệt tất cả các phương thức đó cho String.

Hợp đồng nhất quán cho ==các Đối tượng là nó chỉ là đẳng thức tham chiếu và .equals(Object o)tồn tại cho tất cả các đối tượng cần kiểm tra sự bằng nhau về giá trị. Biến chứng này phức tạp quá nhiều thứ.

Java không hỗ trợ quá tải toán tử, có nghĩa là ==chỉ áp dụng cho các kiểu nguyên thủy hoặc tham chiếu. Bất cứ điều gì khác đòi hỏi phải có một phương thức. Tại sao các nhà thiết kế đã làm điều này là một câu hỏi chỉ họ có thể trả lời. Nếu tôi phải đoán, có lẽ vì quá tải toán tử mang lại sự phức tạp mà họ không muốn thêm vào.

Tôi không phải là chuyên gia về C #, nhưng các nhà thiết kế ngôn ngữ đó dường như đã thiết lập nó sao cho mọi nguyên thủy là một structvà mọi thứ structlà một đối tượng. Bởi vì C # cho phép quá tải toán tử, sự sắp xếp đó giúp cho mọi lớp không dễ dàng, không chỉ String, làm cho chính nó hoạt động theo cách "mong đợi" với bất kỳ toán tử nào. C ++ cho phép điều tương tự.

Điều này đã được thực hiện khác nhau trong các ngôn ngữ khác.

Trong Object Pascal (Delphi / Free Pascal) và C #, toán tử đẳng thức được xác định để so sánh các giá trị, không phải tham chiếu khi hoạt động trên chuỗi.

Riêng trong Pascal, chuỗi là một kiểu nguyên thủy (một trong những điều tôi thực sự yêu thích về Pascal, việc nhận được NullreferenceException chỉ vì một chuỗi chưa được khởi tạo đơn giản là khó chịu) và có ngữ nghĩa sao chép trên văn bản do đó làm cho (hầu hết thời gian) hoạt động chuỗi giá rẻ (nói cách khác, chỉ đáng chú ý khi bạn bắt đầu nối chuỗi nhiều megabyte).

Vì vậy, đó là một quyết định thiết kế ngôn ngữ cho Java. Khi họ thiết kế ngôn ngữ, họ đã làm theo cách C ++ (như Std :: String) để các chuỗi là các đối tượng, đó là IMHO một hack để bù cho C thiếu một loại chuỗi thực, thay vì tạo các chuỗi nguyên thủy (mà chúng là).

Vì vậy, vì một lý do tại sao, tôi chỉ có thể suy đoán họ đã làm điều đó để dễ dàng về phía họ và không mã hóa toán tử tạo một ngoại lệ trên trình biên dịch thành chuỗi.

Trong Java, không có toán tử nào quá tải bất cứ điều gì và đó là lý do tại sao các toán tử so sánh chỉ bị quá tải cho các kiểu nguyên thủy.

Lớp 'Chuỗi' không phải là nguyên thủy, do đó nó không bị quá tải cho '==' và sử dụng mặc định so sánh địa chỉ của đối tượng trong bộ nhớ của máy tính.

Tôi không chắc chắn, nhưng tôi nghĩ rằng trong Java 7 hoặc 8 oracle đã tạo một ngoại lệ trong trình biên dịch để nhận ra str1 == str2làstr1.equals(str2)

Java dường như đã được thiết kế để duy trì một quy tắc cơ bản rằng ==toán tử phải hợp pháp bất cứ khi nào một toán hạng có thể được chuyển đổi thành loại của toán tử khác và nên so sánh kết quả của chuyển đổi đó với toán hạng không được chuyển đổi.

Quy tắc này hầu như không phải là duy nhất đối với Java, nhưng nó có một số ảnh hưởng sâu rộng (và không may IMHO) đối với việc thiết kế các khía cạnh liên quan đến loại khác của ngôn ngữ. Sẽ rõ ràng hơn khi chỉ định các hành vi ==liên quan đến các kết hợp cụ thể của các loại toán hạng và cấm kết hợp các loại X và Y ở đâu x1==y1và x2==y1sẽ không ngụ ý x1==x2, nhưng các ngôn ngữ hiếm khi làm điều đó [theo triết lý đó, double1 == long1sẽ phải chỉ ra liệu double1không phải là một đại diện chính xác của long1, hoặc người khác từ chối biên dịch;int1==Integer1nên bị cấm, nhưng nên có một phương tiện không ném thuận tiện và hiệu quả để kiểm tra xem một đối tượng có phải là số nguyên được đóng hộp với giá trị cụ thể hay không (so sánh với thứ không phải là số nguyên được đóng hộp đơn giản false).

Liên quan đến việc áp dụng ==toán tử cho các chuỗi, nếu Java đã cấm so sánh trực tiếp giữa các toán hạng loại Stringvà Object, thì nó cũng có thể tránh được những bất ngờ trong hành vi của nó ==, nhưng không có hành vi nào có thể thực hiện để so sánh như vậy sẽ không gây ngạc nhiên. Có hai tham chiếu chuỗi được giữ theo kiểu Objectkhác với các tham chiếu được giữ theo kiểu Stringsẽ ít gây ngạc nhiên hơn nhiều so với các hành vi đó khác với so sánh giữa các loại so sánh hợp pháp. Nếu String1==Object1là hợp pháp, điều đó có nghĩa là cách duy nhất cho các hành vi String1==String2và Object1==Object2đối sánh String1==Object1sẽ là chúng khớp với nhau.

Nói chung, có lý do rất chính đáng để muốn có thể kiểm tra nếu hai tham chiếu đối tượng trỏ đến cùng một đối tượng. Tôi đã có rất nhiều lần tôi đã viết

Address oldAddress;
Address newAddress;
... populate values ...
if (oldAddress==newAddress)
... etc ...

Tôi có thể có hoặc không có chức năng bằng trong những trường hợp như vậy. Nếu tôi làm, hàm bằng có thể so sánh toàn bộ nội dung của cả hai đối tượng. Thường thì nó chỉ so sánh một số định danh. "A và B là các tham chiếu đến cùng một đối tượng" và "A và B là hai đối tượng khác nhau có cùng nội dung", tất nhiên, là hai ý tưởng rất khác nhau.

Có lẽ đúng là đối với các đối tượng bất biến, như String, đây không phải là vấn đề. Với các đối tượng bất biến, chúng ta có xu hướng nghĩ về đối tượng và giá trị là cùng một thứ. Chà, khi tôi nói "chúng ta", ít nhất tôi có nghĩa là "tôi".

Integer three=new Integer(3);
Integer triangle=new Integer(3);
if (three==triangle) ...

Tất nhiên điều đó trả về sai, nhưng tôi có thể thấy ai đó nghĩ rằng nó phải đúng.

Nhưng một khi bạn nói rằng == so sánh các thẻ điều khiển tham chiếu và không phải nội dung cho các Đối tượng nói chung, việc tạo một trường hợp đặc biệt cho Chuỗi sẽ có khả năng gây nhầm lẫn. Như một người khác ở đây đã nói, nếu bạn muốn so sánh tay cầm của hai đối tượng String thì sao? Sẽ có một số chức năng đặc biệt để làm điều đó chỉ cho Chuỗi?

Và thế còn ...

Object x=new String("foo");
Object y=new String("foo");
if (x==y) ...

Điều đó có sai vì chúng là hai đối tượng khác nhau hay đúng vì chúng là Chuỗi có nội dung bằng nhau?

Vì vậy, có, tôi hiểu làm thế nào các lập trình viên bị nhầm lẫn bởi điều này. Tôi đã tự làm điều đó, ý tôi là viết nếu myString == "foo" khi tôi có nghĩa là nếu myString.equals ("foo"). Nhưng thiếu thiết kế lại ý nghĩa của toán tử == cho tất cả các đối tượng, tôi không thấy cách giải quyết nó.

Đây là một câu hỏi hợp lệ cho Strings, và không chỉ cho các chuỗi, mà còn cho các đối tượng bất biến khác đại diện cho một số "giá trị", ví dụ Double, BigIntegervà thậm chí InetAddress.

Để làm cho ==toán tử có thể sử dụng được với Chuỗi và các lớp giá trị khác, tôi thấy ba lựa chọn thay thế:

• Trình biên dịch biết về tất cả các lớp giá trị này và cách so sánh nội dung của chúng. Nếu đó chỉ là một số ít các lớp trong java.langgói, tôi sẽ xem xét điều đó, nhưng điều đó không bao gồm các trường hợp như InetAddress.

• Cho phép toán tử quá tải để một lớp xác định ==hành vi so sánh của nó .

• Xóa các hàm tạo công khai và có các phương thức tĩnh trả về các thể hiện từ một nhóm, luôn trả về cùng một thể hiện cho cùng một giá trị. Để tránh rò rỉ bộ nhớ, bạn cần một cái gì đó như SoftReferences trong nhóm, vốn không tồn tại trong Java 1.0. Và bây giờ, để duy trì khả năng tương thích, các nhà String()xây dựng không thể được gỡ bỏ nữa.

Điều duy nhất vẫn có thể được thực hiện ngày hôm nay là giới thiệu quá tải toán tử và cá nhân tôi không muốn Java đi theo con đường đó.

Đối với tôi, khả năng đọc mã là quan trọng nhất và một lập trình viên Java biết rằng các toán tử có nghĩa cố định, được định nghĩa trong đặc tả ngôn ngữ, trong khi các phương thức được xác định bởi một số mã và ý nghĩa của chúng phải được tìm kiếm trong Javadoc của phương thức. Tôi muốn ở lại với sự khác biệt đó ngay cả khi điều đó có nghĩa là các phép so sánh Chuỗi sẽ không thể sử dụng ==toán tử.

Chỉ có một khía cạnh so sánh của Java gây khó chịu cho tôi: hiệu quả của tự động đấm bốc và -unboxing. Nó che giấu sự phân biệt giữa kiểu nguyên thủy và kiểu bao bọc. Nhưng khi bạn so sánh chúng với ==, chúng RẤT khác nhau.

    int i=123456;
    Integer j=123456;
    Integer k=123456;
    System.out.println(i==j);  // true or false? Do you know without reading the specs?
    System.out.println(j==k);  // true or false? Do you know without reading the specs?