Tôi đã đọc qua các chi tiết của các phương thứcthư viện set và get nhưng các tham số thường là Chuỗi.Java: `enum` so với` Chuỗi` làm Tham số
Bạn có xem xét việc sử dụng String làm thông số không đúng kể từ khi bao gồm enum không?
Một giải pháp thay thế tốt hơn ở mức tối thiểu có thể là public final String, Không?
Tôi xem Enums là một cách tiếp cận tốt hơn so với Chuỗi. Họ là loại an toàn và so sánh chúng nhanh hơn so sánh Strings.
Là phiên bản Java 1.5 trước, bạn có thể sử dụng mẫu enum an toàn loại được đề xuất bởi Joshua Bloch trong cuốn sách Effective Java của mình. Đối với các loại enums an toàn loại xem thêm http://www.javacamp.org/designPattern/enum.html
Tôi đã học được "phương pháp ít ngạc nhiên nhất". Theo bản năng, sử dụng enum là điều đúng. Vì vậy, tôi sẽ đi cho nó. Tôi chắc rằng các nhà sản xuất Java nghĩ như nhau.
Sửa: Tuyệt vời giải thích về POLS: http://benpryor.com/blog/2006/06/29/api-design-the-principle-of-least-surprise/
Chỉ vì bạn khai báo một public final String như một cái gì đó mà bạn mong muốn đã trôi qua vào một phương pháp như một tham số, có gì ngăn cản tôi từ đi qua trong bất cứ điều gì tôi thích.
Sử dụng enum s có nghĩa là tôi không thể tạo đối tượng của riêng mình để truyền vào, bảo vệ cả hai mặt của vấn đề. Thời gian duy nhất tôi có thể nghĩ rằng bạn nên sử dụng Strings liên tục thay cho enums là nếu bạn cần cho phép người dùng mở rộng phương thức của bạn để kích hoạt chức năng tùy chỉnh ...
Nếu bạn đang tham chiếu đến System.setProperty(), System.getProperty(), hoặc System.getenv(), tôi nghĩ rằng Strings là thích hợp ở đây kể từ khi tập hợp các phím có thể được mở. Tham số khóa tương ứng với giá trị loại văn bản/chuỗi thực trong một số tệp hoặc lưu trữ ở đâu đó.
Nếu bạn có một bộ khóa kín, tôi nghĩ rằng enums sẽ được ưa thích hơn nhiều.
Suy nghĩ của tôi về điều này là một enum có thể có chi tiết bản đồ cho các thiết lập không nền tảng cụ thể, cả hai nên được sử dụng không chỉ là dây, và các phương pháp chuỗi đó sẽ không được dùng nữa để khuyến khích việc chấp nhận enums –
Tôi nghĩ sự khác biệt giữa "đóng" phím và phím "mở" là yếu tố quan trọng nhất ở đây. Nếu bạn nhìn vào một API với các plugin được nạp động, các plugin có thể đóng góp các chức năng bổ sung có thể được truy cập thông qua một tham số String, nhưng sẽ khó khăn hơn với một enum. –
Việc sử dụng các chuỗi trong các API hiện tại không phải là thực tiễn không tốt; thực hành không tốt để thay đổi các API chỉ vì Java hiện đã hỗ trợ cho các enums. Đối với các API mới, tôi đồng ý với những gì mọi người khác đã nói.
Quá tải? Bản sao bình luận của tôi về lycono: "Ý nghĩ của tôi về điều này là một enum có thể có các chi tiết lập bản đồ cho các thiết lập không nền tảng cụ thể, cả hai nên được sử dụng không chỉ là chuỗi, và các phương thức chuỗi đó sẽ không được dùng để khuyến khích việc chấp nhận enums" –
Nếu tập hợp các thông số của bạn bị giới hạn và được biết đến lúc biên dịch, hãy sử dụng enum.
Nếu tập hợp các tham số của bạn mở và không rõ tại thời gian biên dịch, hãy sử dụng chuỗi.
Mặc dù sử dụng enums là loại an toàn, nhu cầu chuyển đổi enum thành chuỗi và ngược lại là khá thường xuyên. Và không có tính năng tích hợp để làm điều đó trong Java. Và cuối cùng bạn sẽ sử dụng hàm valueOf() và toString(). Và sử dụng cách tiếp cận đó sẽ không khác nhiều so với việc sử dụng các chuỗi. Bởi vì bạn sẽ cần phải xử lý các tình huống mà chuỗi không thể được chuyển đổi thành Enum.
Vì vậy, chỉ cần sử dụng chuỗi cuối cùng tĩnh là dễ dàng và là một thực tế phổ biến, AFAIK.
Ví dụ: bạn sẽ muốn tương tác với máy chủ bằng cách sử dụng một số API. Bạn sẽ cần phải xác định mọi phương thức và phản hồi là Enum. Và sau đó bạn sẽ cần thêm các phương thức toString và valueOf. Tại sao không sử dụng String?
@Martin: Tôi nghĩ suy nghĩ của việc so sánh các đầu vào với chuỗi const nếu không ném một ngoại lệ đầu vào không hợp lệ, không tốt đẹp. Tôi hỏi câu hỏi vì gợi ý về các khóa mở, điều này dường như làm giảm khái niệm WORA trong Java. –