đoạn mã được gọi chỉ một lần - giá trị của phương pháp riêng?

Question

Từ quan sát mã nguồn cho các ứng dụng Android khác nhau (không phải do tôi viết), tôi nhận thấy một mẫu đặt các đoạn mã nhất định vào các phương thức riêng của chúng, mặc dù thực sự không sử dụng lại mã, vì các phương thức này chỉ được gọi một lần trong suốt toàn bộ ứng dụng. Cho đến bây giờ, tôi đã có một quy tắc chung cho thấy nếu một đoạn mã được sử dụng hai lần hoặc nhiều hơn trong mã ứng dụng, thì nó xứng đáng với phương pháp riêng của nó, đơn giản là vì lý do loại bỏ sự dư thừa mã.

Nhưng nhìn thấy những đoạn mã được chia nhỏ gọn thành các phương thức riêng (và phương thức gọi điện riêng), tôi bắt đầu có thể tôi đang thiếu thứ gì đó.

Khác với mục đích tài liệu, lý do nào khác có thể biện minh cho việc chỉ đặt 4 dòng mã (được gọi chỉ một lần!) Vào phương pháp riêng?

Answer 1

Có một vài lý do tôi có thể nghĩ đến, mặc dù phải thừa nhận là có một số chồng chéo:

• Nó giúp làm cho mã tự tài liệu của bạn.
• Nó làm cho (đơn vị) thử nghiệm dễ dàng hơn.
• Điều này giúp bạn dừng việc kết thúc bằng các phương pháp dài hàng trăm dòng.
• Bạn có thể muốn sử dụng mã đó ở một nơi khác trong tương lai.

Tất nhiên, tất cả điều này dựa trên giả định rằng 4 dòng mã đó có liên quan và thực hiện một hàm duy nhất. Tôi thấy rằng một nguyên tắc tốt là: nếu bạn không thể nghĩ ra tên cho nó, nó có lẽ không phải là một phương pháp.

Answer 2

Xem các biện minh như được đưa ra cho việc tái cấu trúc Compose Method.

Answer 3

tài liệu và khả năng đọc là lý do rất tốt để đưa mã vào các phương thức, ngay cả khi các phương pháp đó sẽ chỉ được thực hiện một lần. Một số ứng dụng có thể có một loạt các bước hợp lý để hoàn tất khi khởi động .... bạn có muốn tất cả mã đó bị xáo trộn trong một phương thức init hay phương thức init gọi các phương thức được đặt tên đúng không?

Answer 4

Ba lý do để bắt đầu với:

• Bạn có thể kiểm tra nó trong tách từ bất cứ điều gì khác. (Điều này có thể sẽ đi ngược lại câu thần chú về việc chỉ thử nghiệm các API công khai, nhưng điều đó là tốt cho tôi. Thật khó chịu nếu tôi phải tạo một gói phương thức cấp thay vì riêng tư để kiểm tra nó, nhưng tôi muốn làm điều đó hơn Bạn có thể xây dựng một phương thức phức tạp hơn từ các phương thức đơn giản, trong đó toàn bộ phương thức phức tạp ở mức trừu tượng duy nhất, mà không chỉ rõ chi tiết. Đọc phương pháp mức cao có nghĩa là chỉ đọc tên của các khối xây dựng mà nó tạo thành từ; sau đó bạn có thể đi sâu vào chỉ chi tiết bạn quan tâm nếu cần.
• Bạn có thể viết phương pháp mà mỗi làm một việc tốt, tên và ghi lại chúng trong một cách rõ ràng

Tất nhiên điều này có thể quá trớn, nhưng nó chắc chắn có thể hữu ích.

Answer 5

Nó hy vọng tạo điều kiện cho mã sạch hơn và cần kiểm tra dễ dàng hơn.

Bạn đề cập đến chi phí gọi phương thức, nhưng điều đó không đáng quan tâm nếu phương pháp chỉ được gọi một lần.

Answer 6

Khả năng đọc là lý do chính của tôi đối với hành vi mã hóa như vậy.

Nếu tôi đang nhìn vào một danh sách mã dài, tìm kiếm một quy trình cụ thể hoặc một phần mã, có thể không rõ ràng vị trí của quy trình hoặc phần mã cụ thể đó.

Tại sao chúng ta viết sách trong các đoạn văn và chương? Tại sao các bài hát có những câu thơ/câu thơ, dàn hợp xướng và cầu? Bởi vì nó dễ dàng hơn để đưa vào một ý tưởng lớn trong nhỏ, rất cụ thể, khối.

Nhiều như phát triển phần mềm là tất cả về việc thúc đẩy mã hiệu quả, sạch sẽ giúp công việc được thực hiện nhanh chóng và thanh lịch nhất có thể. Nó cũng phải được đọc bởi những người sẽ duy trì nó.

Ít nhất đó là giải thích của tôi.

Answer 7

Java VM nói chung có giới hạn về kích thước tối đa của phương thức sẽ đủ điều kiện cho nội tuyến. Việc trích xuất mã không thường xuyên được gọi là có thể làm hỏng bánh xe để nói. Bạn có thể chỉ ra các ví dụ?