2013-04-28 36 views
5

Tại sao phương pháp isJavaLetterOrDigit trong số java.lang.Character không được chấp nhận?Tại sao isJavaLetterOrDigit không được dùng nữa?

Tài liệu nói rằng phương pháp isJavaIdentifierPart nên được sử dụng thay thế, nhưng không cho biết lý do. Các tài liệu cho hai phương pháp là nếu không giống hệt nhau. Googling đối tượng đã không đưa ra bất kỳ lời giải thích.

Thực tế, tìm kiếm mã nguồn cho thấy ngày nay, người ta chỉ gọi cho người khác, vì vậy không có sự khác biệt về hành vi. Có phải nó chỉ bị phản đối vì nó có một cái tên khó hiểu hơn? Có vẻ như một quyết định khá kỳ lạ.

@Deprecated 
public static boolean isJavaLetterOrDigit(char ch) { 
    return isJavaIdentifierPart(ch); 
} 

Trả lời

5

Tên cũ (không được chấp nhận) không phản ánh đúng những gì triển khai thực sự thực hiện; ví dụ. nó chấp nhận các ký tự không phải là chữ cái hoặc chữ số. Tôi tưởng tượng điều này sẽ dẫn đến một vài "lỗi" báo cáo và yêu cầu hỗ trợ từ các nhà phát triển nhầm lẫn. IMO, đó là lý do có khả năng nhất mà họ đã thực hiện (đáng kể) bước tạo phương thức mới và không dùng phương pháp cũ nữa.

(Các lý do khác được đề xuất bởi @HuiZheng là các điểm hợp lệ ở cấp độ trí tuệ, nhưng KHÔNG đủ để biện minh cho việc phản đối một phương pháp. làm việc cho các nhà phát triển, và Oracle không muốn xa lánh các công ty trả lương cho những lập trình viên này. Java đã thu hút được rất nhiều sự chú ý trong thế giới doanh nghiệp vì danh tiếng của nó là một nền tảng ổn định!)

Dù sao, không dùng phương pháp này. với tôi) giống như một quyết định thiết kế API rõ ràng và hợp lý được thực hiện vì những lý do chính đáng. Dù bằng cách nào, ý kiến ​​của chúng tôi là tranh luận.

5

Lý do 1:

Một tên API tốt thì có thể đủ trừu tượng (nhưng không quá trừu tượng). isJavaLetterOrDigit quá định hướng triển khai. Nếu bạn thực sự muốn điều đó, hãy sử dụng isLetterOrDigit để thay thế.

Lý do 2:

Một tên API tốt nên xác định chính xác mục đích của nó và cần được thực hiện một cách chính xác. isJavaLetterOrDigit là từ sai vì nó thực sự cho phép ký tự không phải chữ cái ORDigit như "_" hoặc "$".

Lý do 3:

Một tên API tốt nên hài hòa với những người khác. isJavaIdentifierPart phù hợp với các API khác như isJavaIdentifierStart, isUnicodeIdentifierPart, isIdentifierIgnorable.

Cuối cùng, chỉ vì không có sự khác biệt về hành vi giữa hai API này không có nghĩa là chúng giống nhau. Tên API gây hiểu lầm ngộ độc mã của bạn. Hơn nữa, luôn bỏ các API không được chấp nhận càng sớm càng tốt, vì cuối cùng chúng sẽ bị các nhà cung cấp thư viện bán phá giá (hoặc rất có thể).

+1

Chúng không thể bị nhà cung cấp thư viện bán phá giá vì lý do tương thích nhị phân. – EJP

+0

@EJP Tôi biết vì lý do tương thích, các API không dùng nữa thường được lưu giữ trong một thời gian. Nhưng về lâu dài, nhà cung cấp thư viện có thể chọn phá vỡ tính tương thích đó. Dù sao, chúng tôi không muốn chấp nhận rủi ro đó. –

+1

@HuiZheng - Dựa trên lịch sử trong quá khứ, phương pháp sẽ không bị xóa. Nó sẽ không ở trong Oracle hoặc của nó (trả tiền) khách hàng quan tâm để làm điều này. Tài liệu nói rằng điều này * có thể xảy ra ... nhưng tôi dự đoán rằng nó sẽ không *.(Hoặc ít nhất, nó sẽ không trừ khi Oracle có thể cung cấp các công cụ đáng tin cậy để tự động nâng cấp mã cũ ở mã nguồn AND bytecode.) –

Các vấn đề liên quan