Có sử dụng thông số đầu ra được coi là thực tế không?

Question

Mỗi lần tôi nhìn thấy một phương pháp là một trong những thông số là một output parameter như

void addTokenErrorsToReport(List<String> tokens, Map<String, Integer> report) 

tôi nhận được cảm giác rằng đây chỉ là đồng bằng sai. Theo quan điểm của tôi, các tham số nói chung nên không thay đổi, và không thay đổi trong một phương thức. Ví dụ: phương pháp trên có thể được viết lại thành

Map<String, Integer> createTokenErrorsReport(List<String tokens) 

Trả lại Map sau đó có thể được hợp nhất với Bản đồ báo cáo gốc.

Giả định này có đúng không? Hoặc cả hai phiên bản đều có thể chấp nhận được?

Answer 1

Giống như hầu hết mọi thứ, nó chỉ là "thực hành không tốt" nếu nó dẫn đến mã hoạt động kém/không đọc được/khó duy trì hoặc nếu bạn không biết tại sao bạn làm như vậy.

Trong hầu hết các trường hợp, sử dụng thông số đầu ra không có các hiệu ứng đó.

Trong addTokenErrorsToReport của bạn, nó chắc chắn là một cách tiếp cận phù hợp. Bạn đang thêm lỗi mã thông báo vào báo cáo - chức năng cần biết mã thông báo mà nó đang thêm và báo cáo được thêm vào. Chức năng thực hiện chính xác hoạt động mà nó được thiết kế để thực hiện mà không bị bất lợi.

Nếu bạn sử dụng phương pháp createTokenErrorsReport, bạn sẽ phải thực hiện theo mọi cuộc gọi đến đó bằng cách chèn mã thông báo mới vào báo cáo hiện tại. Nếu thêm mã thông báo vào báo cáo hiện tại là một thao tác phổ biến, điều đó chắc chắn có ý nghĩa để có phương thức bổ sung. Đó không phải là để nói rằng createTokenErrorsReport cũng không nên tồn tại - nếu tạo các báo cáo mới từ một danh sách mã thông báo là một hoạt động phổ biến, thì bạn sẽ muốn có một hàm thực hiện điều đó.

Ví dụ tuyệt vời về việc sử dụng tốt thông số đầu ra là Collections.sort, sắp xếp danh sách tại chỗ. Các hit hiệu suất của việc tạo ra một bản sao mới của danh sách và trả lại các bản sao được sắp xếp là tránh, trong khi đồng thời nó không giới hạn bạn từ việc tạo ra một bản sao và phân loại các bản sao nếu bạn muốn.

Chỉ cần sử dụng công cụ tốt nhất cho công việc và giữ mã của bạn gọn gàng.

Answer 2

Tôi nghĩ điều đó phụ thuộc vào nơi bạn đến từ (ngôn ngữ). Nếu bạn sử dụng để viết c hoặc C++, nơi bạn có thể sử dụng con trỏ như các tham số, đó là tốt đẹp và thiết thực, bạn có thể dễ dàng viết mã như ví dụ đầu tiên của bạn. Tôi không thực sự nghĩ rằng có một số loại tốt hay xấu nhưng chỉ cách phong cách của bạn là mã hóa.

Answer 3

Tôi đã thấy thực hành mã hóa này một cách hợp lý thường xuyên và thấy nó khá thanh lịch. Nó cho phép bạn 'trả lại' nhiều đối tượng.

Ví dụ: trong ví dụ trên, bạn có thể trả lại giá trị số nguyên tương ứng với mã lỗi.

Answer 4

Bạn sẽ thêm thứ gì đó vào bản đồ trong ví dụ thứ hai như thế nào? Tôi nghĩ rằng nó sẽ là thực hành xấu nếu bạn phải vượt qua một bản đồ trống được điền vào addTokenErrorsToReport. Nhưng trong trường hợp này: không, tôi không nghĩ đó là hành động xấu. Làm thế nào bạn sẽ thực hiện nếu không, nếu bạn có một số List<String> tokens mà bạn muốn xử lý? Tôi nghĩ ví dụ đầu tiên là một ví dụ đơn giản.