Là quá nhiều thông số, một vấn đề hình ảnh hay logic?

theo Có hướng dẫn nào về việc một hàm nên chấp nhận bao nhiêu tham số không? , một phương thức không nên có quá nhiều tham số. Tuy nhiên, một số câu trả lời cho thấy vấn đề này có thể được giải quyết bằng mẫu xây dựng:

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

hoặc đóng gói các tham số trong một đối tượng.

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

Nhưng tôi nghi ngờ nếu nó giải quyết được vấn đề, bởi vì tôi nghĩ các phương pháp về việc sắp xếp các tham số theo cách tốt hơn (nghĩa là: từ chiều ngang sang chiều dọc), nhưng nó không thay đổi bản chất rằng các tác vụ phụ thuộc vào quá nhiều tham số. Và nếu tôi muốn chuỗi tham số có giao diện tốt hơn, tôi có thể sử dụng một dòng mới cho mỗi tham số như nó:

https://softwareengineering.stackexchange.com/a/331680/248528

Vì vậy, câu hỏi của tôi là "quá nhiều tham số" là một vấn đề trực quan (khó đọc một dòng mã dài) hay vấn đề logic (bản chất nhiệm vụ phụ thuộc vào quá nhiều tham số và cần phá vỡ)? Nếu nó liên quan nhiều hơn đến một vấn đề trực quan, liệu một dòng mới cho mỗi tham số có giải quyết được vấn đề không?

Đây là vấn đề logic đầu tiên và thường đi kèm với vấn đề thị giác. Giải pháp sai cho vấn đề này là chỉ cố gắng cải thiện vấn đề thị giác bằng cách

đóng gói các tham số trong một đối tượng duy nhất [...] chỉ cần căn chỉnh các tham số theo cách tốt hơn (nghĩa là: từ chiều ngang đến chiều dọc)

Đóng gói các tham số trong một đối tượng không có nghĩa là đặt năm tham số vào một thùng chứa tùy ý với một số tên vô nghĩa như thế ObjectParam. Thay vào đó, đóng gói một nhóm các tham số trong một đối tượng sẽ tạo ra một sự trừu tượng hóa mới (hoặc sử dụng lại một tham số hiện có). Giống

• đóng gói ba tham số "X, Y, Z" trong một tham số "vị trí của loại Point3Dhoặc

• đóng gói các tham số "startDate, endDate" trong một đối tượng DateIntervalhoặc

• đóng gói các tham số documentTitle, documentText, authortrong một đối tượng Documentnhóm các tham số này lại với nhau

Nếu phương thức bị đe dọa có nhiều tham số không liên quan, bạn không thể đưa ra một tên nhóm tốt, thì nó có thể có quá nhiều tham số và quá nhiều trách nhiệm.

Một phương thức lấy nhiều tham số thực chất là một bước đi ngược lại so với quy ước về phương pháp cấu hình , xoay quanh việc đơn giản hóa các cuộc gọi như vậy mà không mất khả năng thay đổi giá trị khi cần thiết thông qua việc sử dụng các giá trị mặc định hợp lý .

Nói cách khác, rõ ràng bạn không muốn mất tính linh hoạt, nhưng bạn gần như chắc chắn không cần mọi thông số duy nhất được truyền động. Nhiều thông số tốt có khả năng sẽ được cố định / tĩnh. Lấy một chương trình zip làm ví dụ. Có, có lẽ bạn có thể muốn thay đổi thuật toán nén, mức độ nén, số lượng lõi CPU để dành cho nhiệm vụ, .. bất cứ điều gì. Vấn đề là không ai muốn chỉ định tất cả các tham số này mỗi lần bạn cần tạo tệp zip, giảm hiệu quả cuộc gọi bằng cách cung cấp các yếu tố cần thiết (ví dụ tên tệp zip đích, tệp để thêm vào tệp zip).

Những lý do bạn sử dụng quy ước về cách tiếp cận cấu hình là những lý do tương tự tại sao bạn không nên có các phương thức yêu cầu nhiều tham số. Tóm lại, đơn giản là tốt.