Kỹ thuật giảm thiểu số lượng đối số chức năng

Trong Clean Code, người ta viết rằng "số lượng đối số lý tưởng cho hàm là 0". Những lý do tại sao được giải thích và có ý nghĩa. Những gì tôi đang theo là các kỹ thuật để cấu trúc lại các phương thức với 4 hoặc nhiều đối số để giải quyết vấn đề này.

Một cách là trích xuất các đối số vào một lớp mới, nhưng điều đó chắc chắn sẽ dẫn đến sự bùng nổ của các lớp? Và các lớp đó có khả năng kết thúc bằng các tên vi phạm một số quy tắc đặt tên (kết thúc bằng "Dữ liệu" hoặc "Thông tin", v.v.)?

Một kỹ thuật khác là biến các biến được sử dụng bởi nhiều hàm thành một biến thành viên riêng để tránh truyền chúng, nhưng điều đó mở rộng phạm vi của biến, có thể là nó mở cho các hàm không thực sự cần nó.

Chỉ cần tìm cách để giảm thiểu các đối số chức năng, đã chấp nhận các lý do tại sao nên làm như vậy.

Điều quan trọng nhất cần nhớ là đó là những hướng dẫn, không phải là quy tắc.

Có những trường hợp một phương thức đơn giản phải lấy một đối số. Hãy suy nghĩ về +phương pháp cho các số, ví dụ. Hoặc addphương pháp cho một bộ sưu tập.

Trong thực tế, người ta thậm chí có thể lập luận rằng ý nghĩa của việc thêm hai số phụ thuộc vào ngữ cảnh, ví dụ như trong ℤ 3 + 3 == 6, nhưng trong ℤ _{| 5} 3 + 3 == 2 , vì vậy, toán tử bổ sung phải là một phương thức trên một đối tượng bối cảnh có hai đối số thay vì một đối số phương pháp trên các số có một đối số.

Tương tự, một phương thức để so sánh hai đối tượng phải là phương thức của một đối tượng lấy đối tượng kia làm đối số hoặc phương thức của bối cảnh, lấy hai đối tượng làm đối số, vì vậy đơn giản là không có phương thức so sánh với ít hơn một đối số.

Điều đó nói rằng, có một vài điều có thể được thực hiện để giảm số lượng đối số cho một phương thức:

• Làm cho phương thức tự nhỏ hơn : Có thể, nếu phương thức cần nhiều đối số, thì nó đang làm quá nhiều?
• Một sự trừu tượng bị thiếu : Nếu các đối số có mối tương quan chặt chẽ với nhau, có thể chúng thuộc về nhau và có một sự trừu tượng hóa mà bạn đang thiếu? (Ví dụ về sách giáo khoa Canonical: thay vì hai tọa độ, truyền một Pointđối tượng hoặc thay vì chuyển tên người dùng và email, hãy chuyển một IdCardđối tượng.)
• Trạng thái đối tượng : Nếu đối số là cần thiết bởi nhiều phương thức, có lẽ nó phải là một phần của trạng thái đối tượng. Nếu nó chỉ cần một số phương thức chứ không phải các phương thức khác, có thể đối tượng đang làm quá nhiều và thực sự phải là hai đối tượng.

Một cách là trích xuất các đối số vào một lớp mới, nhưng điều đó chắc chắn sẽ dẫn đến sự bùng nổ của các lớp?

Nếu mô hình miền của bạn có nhiều loại khác nhau, thì mã của bạn sẽ kết thúc với nhiều loại đối tượng khác nhau. Không có gì sai với điều đó.

Và các lớp đó có khả năng kết thúc bằng các tên vi phạm một số quy tắc đặt tên (kết thúc bằng "Dữ liệu" hoặc "Thông tin", v.v.)?

Nếu bạn không thể tìm thấy một tên thích hợp, có thể bạn đã nhóm quá nhiều đối số lại với nhau hoặc quá ít. Vì vậy, bạn chỉ có một mảnh của một lớp hoặc bạn có nhiều hơn một lớp.

Một kỹ thuật khác là biến các biến được sử dụng bởi nhiều hàm thành một biến thành viên riêng để tránh truyền chúng, nhưng điều đó mở rộng phạm vi của biến, có thể là nó mở cho các hàm không thực sự cần nó.

Nếu bạn có một nhóm phương thức tất cả các phương thức hoạt động trên cùng một đối số và một nhóm phương thức khác không có, có thể chúng thuộc các lớp khác nhau.

Lưu ý tần suất tôi sử dụng từ "có thể"? Đó là lý do tại sao đó là hướng dẫn, không phải là quy tắc. Có lẽ phương pháp của bạn với 4 tham số là hoàn toàn tốt!

Lưu ý rằng không có đối số nào không ngụ ý tác dụng phụ, bởi vì đối tượng của bạn là đối số ngầm. Ví dụ, hãy xem có bao nhiêu phương pháp không có danh sách của Scala .

Một kỹ thuật hữu ích tôi gọi là kỹ thuật "lấy nét ống kính". Khi bạn lấy nét ống kính máy ảnh, sẽ dễ dàng hơn để nhìn thấy điểm lấy nét thực sự nếu bạn đưa nó đi quá xa, sau đó đưa nó trở lại điểm chính xác. Điều tương tự cũng đúng với tái cấu trúc phần mềm.

Đặc biệt nếu bạn đang sử dụng kiểm soát phiên bản phân tán, các thay đổi phần mềm rất dễ thử nghiệm, hãy xem bạn có thích giao diện của chúng không và tắt đi nếu bạn không, nhưng vì một số lý do, mọi người thường có vẻ miễn cưỡng làm như vậy.

Trong ngữ cảnh của câu hỏi hiện tại của bạn, điều đó có nghĩa là viết các phiên bản không hoặc một đối số, với một số chức năng được tách ra trước, sau đó tương đối dễ dàng để xem các chức năng nào cần kết hợp để dễ đọc.

Lưu ý rằng tác giả cũng là một người ủng hộ rất lớn cho sự phát triển dựa trên thử nghiệm, có xu hướng tạo ra các hàm có độ yếu thấp ngay từ đầu vì bạn bắt đầu với các trường hợp thử nghiệm tầm thường của mình.

Một cách tiếp cận đơn giản (và ngây thơ - hoặc thậm chí tôi nên nói một cách mù quáng ) chỉ nhằm mục đích giảm số lượng đối số cho các hàm ist có thể sai. Hoàn toàn không có gì sai với các hàm có số lượng lớn đối số. Nếu chúng được logic yêu cầu, thì chúng cũng được yêu cầu ... Một danh sách tham số dài hoàn toàn không làm tôi lo lắng - miễn là nó được định dạng đúng và nhận xét về tính dễ đọc.

Trong trường hợp tất cả hoặc một tập hợp con của các đối số thuộc về một thực thể logic duy nhất và thường được truyền xung quanh trong các nhóm trong suốt chương trình của bạn, có thể có ý nghĩa khi nhóm chúng vào một thùng chứa - Điển hình là một cấu trúc hoặc đối tượng khác. Ví dụ điển hình có thể là một số loại thông điệp hoặc kiểu dữ liệu sự kiện .

Bạn có thể dễ dàng làm quá mức phương pháp đó - một khi bạn thấy rằng việc đóng gói và giải nén các thứ đến và từ các container vận chuyển như vậy sẽ tạo ra nhiều chi phí hơn là cải thiện khả năng đọc, có lẽ bạn đã đi quá xa.

OTOH, danh sách tham số lớn có thể là dấu hiệu cho thấy chương trình của bạn có thể không được cấu trúc đúng - có thể chức năng yêu cầu số lượng lớn tham số như vậy chỉ là cố gắng làm quá nhiều và nên được chia thành nhiều chức năng nhỏ hơn. Tôi muốn bắt đầu ở đây hơn là lo lắng về # tham số.

Không có cách kỳ diệu: bạn phải nắm vững miền vấn đề để khám phá kiến ​​trúc phù hợp. Đó là cách duy nhất để cấu trúc lại: làm chủ miền vấn đề. Hơn bốn tham số chỉ là một sự chắc chắn rằng kiến ​​trúc hiện tại của bạn bị lỗi và sai.

Các ngoại lệ duy nhất là trình biên dịch (siêu dữ liệu) và mô phỏng, trong đó giới hạn là lý thuyết 8, nhưng có lẽ chỉ có 5.