Tại sao tôi nên chuyển Boolean làm tham số thay vì "boolean"?

Question

Một đồng nghiệp yêu cầu tôi thay đổi chữ ký bằng cách sử dụng "boolean" nguyên thủy để sử dụng "Boolean" được phân loại. Anh ta không đưa ra một lời giải thích rất tốt tại sao?

Có ai trong số các bạn đã nghe nói về điều này và bất kỳ ai trong các bạn có thể giải thích tại sao nó quan trọng hay không quan trọng?

Chỉnh sửa: Ông đã đề cập rằng đó là phương pháp hay cho các phương pháp công khai.

Việc sử dụng trường chỉ là một lá cờ cho tôi biết có nên gọi một luồng hay luồng khác tùy theo việc đó là đúng hay sai.

Answer 1

Thực ra tôi có khuynh hướng sai lệch bên cạnh việc chuyển boolean nhỏ b, thay vào đó, bởi vì tôi biết rằng boolean nguyên thủy sẽ không bao giờ là rỗng. Tôi chắc rằng có những lý do hợp lệ để sử dụng kiểu Boolean, nhưng tôi muốn suy nghĩ về việc sử dụng nó trong mỗi trường hợp.

Answer 2

Có liên quan đến cơ sở dữ liệu không? Nếu bạn có một giá trị boolean trong cơ sở dữ liệu, nó có thể giữ một trong ba giá trị - đúng, sai và null. Đối tượng Boolean sẽ cho phép bạn bắt chước hành vi đó.

Về cơ bản, đó là vấn đề liệu bạn có muốn xử lý "null" làm giá trị đầu vào tiềm năng hay không.

Answer 3

Thực tế, nói chung, thực tiễn tốt là sử dụng các nguyên thủy thông thường trừ khi có lý do cụ thể không. Nó sẽ hơi nhanh hơn/ít lãng phí hơn, mặc dù bạn cần phải di chuyển rất nhiều vật thể xung quanh để điều đó thực sự quan trọng.

Để phản hồi chỉnh sửa của bạn, tôi chưa bao giờ nghe nói đó là phương pháp hay cho các phương pháp công khai. Trong Java hiệu quả thường được trích dẫn bởi Josh Bloch, có một mục hoàn toàn "Ưu tiên các kiểu nguyên thủy để đóng gói nguyên thủy" (mục 49, nếu bạn có thể lấy tay trên một bản sao). Có vẻ như trường hợp cụ thể của bạn không có lý do gì để ưu tiên sử dụng Boolean lớn b, và việc sử dụng các đối tượng tạo ra những cạm bẫy như tương tác yếu với mã cũ, ví dụ: sử dụng == thay vì equals() ().

Answer 4

Tôi thường cố gắng sử dụng boolean nguyên thủy bất cứ khi nào có thể. Khả năng duy nhất mà tôi có thể nghĩ cho một nhà phát triển muốn lớp Boolean là boxing/unboxing (nhưng tôi nghĩ bạn muốn ngăn chặn boxing/unboxing bất cứ khi nào có thể thay vì khuyến khích nó ở khắp mọi nơi) và khả năng cho null giá trị.

Answer 5

Nếu bạn kiểm soát cả hai mặt của giao diện (tức là mã gọi và phương thức được gọi) thì bạn chỉ nên nhất quán. Bạn thực sự phải chịu một chút chi phí nếu bạn buộc trình biên dịch tự động tạo biến cho bạn.

Nếu phương pháp được đề cập là một tập hợp các phương thức có chữ ký tương tự, và tất cả các phương thức khác chuyển một đối tượng thuộc loại nào đó ở vị trí mà boolean của bạn đi, thì việc sử dụng đối tượng thay vì nguyên thủy có thể đơn giản là vấn đề được một chút nhất quán hơn.

EDIT: Đọc lại câu hỏi, nếu tham số boolean thực sự chỉ ở đó để kiểm soát if (chính xác là những gì nguyên thủy có), sau đó sử dụng biểu mẫu đối tượng đơn giản là lãng phí thời gian và bộ nhớ CPU . Tôi không thể nghĩ ra một lý do hợp lý tại sao nó phải là một đối tượng chứ không phải là một nguyên thủy.

Answer 6

Ưu điểm chính của Boolean so với boolean nguyên thủy là chúng cho phép bạn có giá trị null. Điều này đặc biệt hiệu quả cho các giá trị trả về nhưng đôi khi có thể được sử dụng cho một đối số "tùy chọn" trong Java.

đảm bảo JavaDocs của bạn (và code) có thể đối phó với các null

Answer 7

Chưa bao giờ nghe nói về bất kỳ lý do chính đáng để thích Boolean qua boolean.

Có cơ hội, luôn gắn bó với nguyên thủy. Các biến Boolean có thể là null; và do đó có thể giới thiệu một hành vi bất ngờ trong phương pháp của bạn. Đồng nghiệp của bạn có thể có một số lý do cụ thể dựa trên việc thực hiện chương trình/logic.

Answer 8

Nếu bạn sử dụng Boolean, sau đó bạn có thể vượt qua một boolean hoặc Boolean với phương pháp

public void setX(boolean b) //only takes boolean 

public void setX(Boolean b) //takes Boolean or boolean 

Điều này là do các autoboxing của boolean vào hàm.

EDIT: Các autoboxing chỉ hoạt động trong 1.5 +

Answer 9

Giữ nó đơn giản. Sử dụng Boolean:

• thêm thêm một lớp phức tạp
• mất/sai boolean thực trạng và chuyển đổi nó vào một đúng/sai/trạng thái rỗng biến
• không cung cấp lợi thế nếu được sử dụng như một lá cờ logic (giả sử không có tương tác cơ sở dữ liệu như đã đề cập bởi BlairHippo)
• có khả năng đòi hỏi dòng bổ sung mã để hộp/boolean Unbox trong Java 1,4

Answer 10

bạn đang sử dụng bất kỳ loại khuôn khổ liên kết dữ liệu trong ứng dụng của bạn? Gần đây tôi đã phải đối phó với một trường hợp trong đó một boolean trong một đối tượng mô hình cần thiết để được ràng buộc vào một biểu mẫu. Trường trong biểu mẫu là bắt buộc, nhưng chúng tôi không muốn đặt giá trị mặc định thành true hoặc false (vì điều quan trọng là người dùng phải chọn giá trị chính xác cho trường hợp cụ thể, nếu có mặc định, bạn sẽ dễ dàng nhận được rất nhiều giá trị không chính xác.) Tuy nhiên, trước khi đối tượng có thể được xác thực, các giá trị từ biểu mẫu phải được ràng buộc với nó. Tất nhiên, nếu người dùng đã không chọn một giá trị, nó sẽ cố gắng ràng buộc null cho trường này và một ngoại lệ sẽ được ném trong khi liên kết. Vì vậy, chúng tôi đã thay đổi nó thành Boolean để null có thể bị ràng buộc vào trường tạm thời và sau đó xác thực có thể báo cáo rằng trường này là bắt buộc.