Khi nào và tại sao bạn nên sử dụng void (thay vì ví dụ bool / int)

Thỉnh thoảng tôi chạy vào các phương thức mà nhà phát triển đã chọn trả về một cái gì đó không quan trọng đối với chức năng. Ý tôi là, khi nhìn vào mã, nó rõ ràng hoạt động tốt như một voidvà sau một lúc suy nghĩ, tôi hỏi "Tại sao?" Điều này nghe có vẻ quen thuộc phải không?

Đôi khi tôi đồng ý rằng thường thì tốt hơn là trả lại một cái gì đó như một bool, hoặc intsau đó chỉ cần làm một void. Mặc dù vậy, tôi không chắc chắn, trong bức tranh lớn, về những ưu và nhược điểm.

Tùy thuộc vào tình huống, trả về một intcó thể làm cho người gọi nhận biết số lượng hàng hoặc đối tượng bị ảnh hưởng bởi phương thức (ví dụ: 5 bản ghi được lưu vào MSSQL). Nếu một phương thức như "Chèn một cái gì đó" trả về một boolean, tôi có thể có phương thức được thiết kế để trả về truenếu thành công, khác false. Người gọi có thể chọn hành động hoặc không dựa trên thông tin đó.

Mặt khác,

• Nó có thể dẫn đến một mục đích ít rõ ràng hơn của một cuộc gọi phương thức? Mã hóa xấu thường buộc tôi phải kiểm tra lại nội dung phương thức. Nếu nó trả về một cái gì đó, nó sẽ cho bạn biết rằng phương thức đó thuộc loại bạn phải làm một cái gì đó với kết quả được trả về.
• Một vấn đề khác là, nếu bạn không biết cách triển khai phương thức, nhà phát triển đã quyết định trả lại cái gì không quan trọng? Tất nhiên bạn có thể nhận xét nó.
• Giá trị trả về phải được xử lý, khi quá trình xử lý có thể kết thúc tại khung đóng của phương thức.
• Điều gì xảy ra dưới mui xe? Có phải phương thức được gọi là falsedo lỗi ném? Hoặc nó đã trả về sai do kết quả đánh giá?

Kinh nghiệm của bạn với điều này là gì? Làm thế nào bạn sẽ hành động về điều này?

Trong trường hợp giá trị trả về bool để chỉ ra sự thành công hay thất bại của một phương thức, tôi thích Trymô hình -prefix được sử dụng trong các phương thức .NET khác nhau.

Ví dụ, một void InsertRow()phương thức có thể đưa ra một ngoại lệ nếu đã tồn tại một hàng có cùng khóa. Câu hỏi là, có hợp lý không khi cho rằng người gọi đảm bảo hàng của họ là duy nhất trước khi gọi insertRow? Nếu câu trả lời là không, thì tôi cũng sẽ cung cấp câu bool TryInsertRow()trả lời sai nếu hàng đã tồn tại. Trong các trường hợp khác, chẳng hạn như lỗi kết nối db, TryInsertRow vẫn có thể đưa ra một ngoại lệ, giả sử rằng việc duy trì kết nối db là trách nhiệm của người gọi.

IMHO trả lại "mã trạng thái" bắt nguồn từ thời điểm lịch sử, trước khi các ngoại lệ trở nên phổ biến trong các ngôn ngữ từ trung cấp đến cao hơn như C #. Ngày nay, tốt hơn hết là ném một ngoại lệ nếu một số lỗi không mong muốn ngăn phương thức của bạn thành công. Bằng cách đó, chắc chắn rằng lỗi không được chú ý và người gọi có thể xử lý khi thích hợp. Vì vậy, trong những trường hợp này, việc phương thức trả về không có gì (nghĩa là void) thay vì cờ trạng thái boolean hoặc mã trạng thái số nguyên là hoàn toàn tốt . (Tất nhiên người ta phải ghi lại những ngoại lệ mà phương thức có thể ném và khi nào.)

Mặt khác, nếu đó là một hàm theo nghĩa chặt chẽ, nghĩa là nó thực hiện một số tính toán dựa trên các tham số đầu vào và dự kiến ​​sẽ trả về kết quả của phép tính đó, kiểu trả về là hiển nhiên.

Có một khu vực màu xám giữa hai người, khi một người có thể quyết định trả lại một số thông tin "phụ" từ phương thức, nếu nó được coi là hữu ích cho người gọi của nó. Giống như ví dụ của bạn về số lượng hàng bị ảnh hưởng trong một chèn. Hoặc đối với một phương thức để đưa một phần tử vào một bộ sưu tập kết hợp, có thể hữu ích để trả về giá trị trước đó được liên kết với khóa đó, nếu có bất kỳ. Việc sử dụng như vậy có thể được xác định bằng cách phân tích cẩn thận các kịch bản sử dụng (đã biết và dự đoán) của API.

Câu trả lời của Peter bao gồm các ngoại lệ tốt. Xem xét khác ở đây liên quan đến phân tách truy vấn lệnh

Nguyên tắc CQS nói rằng một phương thức nên là một lệnh hoặc một truy vấn và không phải cả hai. Các lệnh không bao giờ nên trả về một giá trị, chỉ sửa đổi trạng thái và các truy vấn chỉ nên trả về và không sửa đổi trạng thái. Điều này giữ cho ngữ nghĩa rất rõ ràng và giúp làm cho mã dễ đọc và dễ bảo trì hơn.

Có một vài trường hợp vi phạm nguyên tắc CQS là một ý kiến ​​hay. Đây thường là xung quanh hiệu suất hoặc an toàn chủ đề.

Dù con đường là gì bạn sẽ đi bộ với điều này. Không có giá trị trả về trong đó để sử dụng trong tương lai (ví dụ: có các hàm luôn trả về đúng) đây là một sự lãng phí công sức khủng khiếp và không làm cho mã rõ ràng hơn để đọc. Khi bạn có một giá trị trả về, bạn phải luôn sử dụng nó và để có thể sử dụng nó, bạn nên có ít nhất 2 giá trị trả về có thể.

Tôi đã từng viết rất nhiều hàm void. Nhưng vì tôi đã sử dụng toàn bộ phương pháp bẻ khóa, tôi bắt đầu trả lại cái này thay vì khoảng trống - cũng có thể để ai đó lợi dụng lợi nhuận khiến bạn không thể ngồi xổm với khoảng trống. Và nếu họ không muốn làm bất cứ điều gì với nó, họ có thể bỏ qua nó.