Tại sao không có String.Empty trong Java?

Tôi hiểu rằng mỗi khi tôi nhập chuỗi ký tự "", cùng một đối tượng Chuỗi được tham chiếu trong nhóm chuỗi.

Nhưng tại sao API chuỗi không bao gồm a public static final String Empty = "";, vì vậy tôi có thể sử dụng tài liệu tham khảo String.Empty?

Nó sẽ tiết kiệm thời gian biên dịch, ít nhất, vì trình biên dịch sẽ biết tham chiếu Chuỗi hiện có và không phải kiểm tra xem nó đã được tạo để sử dụng lại chưa, phải không? Và cá nhân tôi nghĩ rằng sự phổ biến của các chuỗi ký tự, đặc biệt là các chuỗi nhỏ, trong nhiều trường hợp là "mùi mã".

Vì vậy, có một Lý do thiết kế lớn đằng sau không có String.Empty, hay những người sáng tạo ngôn ngữ chỉ đơn giản là không chia sẻ quan điểm của tôi?

String.EMPTYlà 12 ký tự và ""là hai ký tự và cả hai sẽ tham chiếu chính xác cùng một thể hiện trong bộ nhớ khi chạy. Tôi không hoàn toàn chắc chắn tại sao String.EMPTYsẽ tiết kiệm thời gian biên dịch, thực tế tôi nghĩ nó sẽ là cái sau.

Đặc biệt là việc xem xét Stringlà không thay đổi, trước tiên bạn không thể có được một Chuỗi trống và thực hiện một số thao tác trên nó - tốt nhất là sử dụng StringBuilder(hoặc StringBuffernếu bạn muốn an toàn cho chuỗi) và biến chuỗi đó thành Chuỗi.

Cập nhật
Từ nhận xét của bạn cho câu hỏi:

Điều gì truyền cảm hứng này thực sự là TextBox.setText("");

Tôi tin rằng việc cung cấp một hằng số trong lớp thích hợp của bạn là hoàn toàn hợp pháp:

private static final String EMPTY_STRING = "";

Và sau đó tham chiếu nó như trong mã của bạn như

TextBox.setText(EMPTY_STRING);

Theo cách này, ít nhất bạn rõ ràng rằng bạn muốn có một Chuỗi trống, thay vì bạn quên điền Chuỗi vào IDE của mình hoặc một cái gì đó tương tự.

Sử dụng org.apache.commons.lang.StringUtils.EMPTY

Nếu bạn muốn so sánh với chuỗi rỗng mà không phải lo lắng về các giá trị null, bạn có thể làm như sau.

if ("".equals(text))

Cuối cùng, bạn nên làm những gì bạn tin là rõ ràng nhất. Hầu hết các lập trình viên đều cho rằng "" có nghĩa là chuỗi rỗng, không phải là chuỗi ai đó quên đặt bất cứ thứ gì vào.

Nếu bạn nghĩ rằng có một lợi thế về hiệu suất, bạn nên kiểm tra nó. Nếu bạn không nghĩ rằng nó đáng để thử nghiệm cho chính mình, thì đó là một dấu hiệu tốt cho thấy nó thực sự không đáng.

Có vẻ như bạn cố gắng giải quyết một vấn đề đã được giải quyết khi ngôn ngữ được thiết kế hơn 15 năm trước.

Nếu bạn thực sự muốn một hằng số String.EMPTY, bạn có thể tạo một lớp cuối cùng tĩnh tiện ích có tên "Hằng số" (ví dụ) trong dự án của bạn. Lớp này sẽ duy trì các hằng số của bạn, bao gồm cả Chuỗi trống ...

Trong cùng một ý tưởng, bạn có thể tạo ZERO, ONE int constants ... không tồn tại trong lớp Integer, nhưng như tôi đã nhận xét, sẽ rất khó để viết và đọc:

for(int i=Constants.ZERO; ...) {
    if(myArray.length > Constants.ONE) {
        System.out.println("More than one element");
    }
}

Vân vân.

Apache StringUtils cũng giải quyết vấn đề này.

Thất bại của các lựa chọn khác:

• isEmpty () - không an toàn. Nếu chuỗi là null, ném NPE
• length () == 0 - một lần nữa không null an toàn. Cũng không tính đến các chuỗi khoảng trắng.
• So sánh với hằng số EMPTY - Có thể không an toàn. Vấn đề khoảng trắng

Được cấp StringUtils là một thư viện khác để kéo xung quanh, nhưng nó hoạt động rất tốt và tiết kiệm rất nhiều thời gian và kiểm tra rắc rối cho null hoặc xử lý NPE một cách duyên dáng.

Đừng chỉ nói "nhóm bộ nhớ của chuỗi được sử dụng lại ở dạng nghĩa đen, trường hợp đóng". Những gì trình biên dịch làm dưới mui xe không phải là điểm ở đây. Câu hỏi là hợp lý, đặc biệt được đưa ra số lượng phiếu bầu nhận được.

Đó là về tính đối xứng , không có API thì khó sử dụng hơn cho con người. SDK Java ban đầu nổi tiếng đã bỏ qua quy tắc và bây giờ thì đã quá muộn. Dưới đây là một vài ví dụ trên đầu tôi, thoải mái để chip trong ví dụ "yêu thích" của bạn:

• BigDecimal.ZERO, nhưng không có AbstractCollection.EMPTY, String.EMPTY
• Array.length nhưng List.size ()
• List.add (), Set.add () nhưng Map.put (), ByteBuffer.put () và chúng ta đừng quên StringBuilder.append (), Stack.push ()

Tất cả những nghĩa ""đen là cùng một đối tượng. Tại sao làm cho tất cả thêm phức tạp? Nó chỉ dài hơn để gõ và ít rõ ràng hơn (chi phí cho trình biên dịch là tối thiểu). Vì các chuỗi của Java là các đối tượng bất biến, nên không bao giờ có nhu cầu phân biệt giữa chúng ngoại trừ có thể là một điều hiệu quả, nhưng với chuỗi ký tự trống thì đó không phải là vấn đề lớn.

Nếu bạn thực sự muốn một EmptyStringhằng số, hãy tự làm nó. Nhưng tất cả những gì nó sẽ làm là khuyến khích mã dài hơn nữa; sẽ không bao giờ có bất kỳ lợi ích để làm như vậy.

Để thêm vào những gì Noel M đã nêu, bạn có thể xem câu hỏi này và câu trả lời này cho thấy hằng số được sử dụng lại.

http://forums.java.net/jive/message.jspa?messageID=17122

Hằng chuỗi luôn luôn được "thực tập", do đó không thực sự cần một hằng số như vậy.

String s=""; String t=""; boolean b=s==t; // true

Tôi hiểu rằng mỗi khi tôi nhập chuỗi ký tự "", cùng một đối tượng Chuỗi được tham chiếu trong nhóm Chuỗi.
Không có sự đảm bảo nào được thực hiện. Và bạn không thể dựa vào nó trong ứng dụng của mình, hoàn toàn tùy thuộc vào quyết định.

hoặc những người sáng tạo ngôn ngữ chỉ đơn giản là không chia sẻ quan điểm của tôi?
Vâng. Đối với tôi, nó có vẻ là điều ưu tiên rất thấp.

Câu trả lời muộn, nhưng tôi nghĩ rằng nó thêm một cái gì đó mới cho chủ đề này.

Không có câu trả lời trước đã trả lời câu hỏi ban đầu. Một số đã cố gắng biện minh cho việc thiếu hằng số, trong khi những người khác đã chỉ ra những cách mà chúng ta có thể đối phó với việc thiếu hằng số. Nhưng không ai đưa ra một lời biện minh thuyết phục cho lợi ích của hằng số, vì vậy sự thiếu sót của nó vẫn chưa được giải thích chính xác.

Một hằng số sẽ hữu ích vì nó sẽ ngăn các lỗi mã nhất định không được chú ý.

Giả sử bạn có một cơ sở mã lớn với hàng trăm tham chiếu đến "". Ai đó sửa đổi một trong những điều này trong khi cuộn qua mã và thay đổi nó thành "". Một sự thay đổi như vậy sẽ có khả năng cao không được chú ý vào sản xuất, tại thời điểm đó nó có thể gây ra một số vấn đề mà nguồn của nó sẽ khó phát hiện.

OTOH, hằng số thư viện có tên EMPTY, nếu có cùng lỗi, sẽ tạo ra lỗi trình biên dịch cho một cái gì đó như EM PTY.

Xác định hằng số của riêng bạn vẫn tốt hơn. Ai đó vẫn có thể thay đổi khởi tạo do nhầm lẫn, nhưng do sử dụng rộng rãi, tác động của lỗi như vậy sẽ khó được chú ý hơn nhiều so với lỗi trong một trường hợp sử dụng.

Đây là một trong những lợi ích chung mà bạn nhận được từ việc sử dụng hằng số thay vì giá trị theo nghĩa đen. Mọi người thường nhận ra rằng việc sử dụng hằng số cho một giá trị được sử dụng ở hàng chục nơi cho phép bạn dễ dàng cập nhật giá trị đó chỉ trong một nơi. Điều ít được thừa nhận là điều này cũng ngăn giá trị đó vô tình bị sửa đổi, bởi vì một thay đổi như vậy sẽ hiển thị ở mọi nơi. Vì vậy, vâng, "" ngắn hơn EMPTY, nhưng EMPTY an toàn hơn khi sử dụng so với "".

Vì vậy, quay trở lại câu hỏi ban đầu, chúng ta chỉ có thể suy đoán rằng các nhà thiết kế ngôn ngữ có thể không nhận thức được lợi ích này của việc cung cấp các hằng số cho các giá trị theo nghĩa đen thường được sử dụng. Hy vọng rằng, một ngày nào đó chúng ta sẽ thấy các hằng chuỗi được thêm vào trong Java.

Đối với những người yêu cầu ""và String.Emptycó thể hoán đổi cho nhau hoặc điều đó ""tốt hơn, bạn rất sai.

Mỗi lần bạn làm một cái gì đó như myVariable = ""; bạn đang tạo một thể hiện của một đối tượng. Nếu đối tượng String của Java có hằng số công khai EMPTY, sẽ chỉ có 1 thể hiện của đối tượng ""

Ví dụ: -

String.EMPTY = ""; //Simply demonstrating. I realize this is invalid syntax

myVar0 = String.EMPTY;
myVar1 = String.EMPTY;
myVar2 = String.EMPTY;
myVar3 = String.EMPTY;
myVar4 = String.EMPTY;
myVar5 = String.EMPTY;
myVar6 = String.EMPTY;
myVar7 = String.EMPTY;
myVar8 = String.EMPTY;
myVar9 = String.EMPTY;

10 (11 bao gồm String.EMPTY) Con trỏ tới 1 đối tượng

Hoặc là: -

myVar0 = "";
myVar1 = "";
myVar2 = "";
myVar3 = "";
myVar4 = "";
myVar5 = "";
myVar6 = "";
myVar7 = "";
myVar8 = "";
myVar9 = "";

10 con trỏ đến 10 đối tượng

Điều này là không hiệu quả và trong suốt một ứng dụng lớn, có thể là đáng kể.

Có lẽ trình biên dịch Java hoặc thời gian chạy đủ hiệu quả để tự động trỏ tất cả các cá thể của "" vào cùng một thể hiện, nhưng nó có thể không và cần xử lý bổ sung để đưa ra quyết định đó.