Phân hủy trong java, khi nào là đủ?

Question

Tôi là sinh viên khoa học máy tính năm đầu tiên. Chúng tôi hiện đang lập trình bằng java và tôi thường cố gắng phân tích chương trình của mình thành các phương thức được đặt tên tốt để logic phương thức chính của tôi có thể đọc gần với mã giả nhất có thể.

Vấn đề tôi thấy là thường xuyên tôi kết thúc bằng văn bản rất nhiều phương pháp riêng tư nhỏ mà tôi cảm thấy tôi có thể đang lạm dụng nó. Có bất kỳ quy tắc ngón tay cái hay cân nhắc phong cách nào tốt để đưa vào tài khoản khi quyết định xem có nên phân tích thêm một vấn đề nào nữa không?

Answer 1

Hầu hết các nhà phát triển mới theo cách khác - các chức năng lớn có nhiều trách nhiệm. Tình huống của bạn vô cùng thích hợp hơn với điều này!

Có rất ít nhược điểm khi tạo nhiều phương thức nhỏ và rất nhiều ưu điểm!

phương pháp ngắn là:

• dễ dàng hơn để tái sử dụng
• dễ dàng hơn để kiểm tra
• dễ dàng hơn để đọc và hiểu
• dễ dàng hơn để gỡ lỗi

Xét này, tôi sẽ đề nghị rằng bạn không thương tiếc tái cấu trúc sao chép thành các phương pháp nhỏ. IDE của bạn sẽ cung cấp cho bạn một phương pháp tái cấu trúc phương thức trích xuất để làm cho việc này nhanh hơn.

Tôi cũng nghĩ rằng mục đích của bạn về tuổi thơ đối với một loại mã giả có thể đọc được, nói chung, một mã tốt. Rất nhiều mã bạn thấy sẽ không được viết như thế này, nhưng nó thực sự có thể hỗ trợ khả năng đọc và khái niệm rằng 'mã là tài liệu.'

Một số người sẽ nói về chi phí hoạt động của các cuộc gọi phương thức, nhưng chỉ trong những trường hợp rất hiếm có thể là một mối quan ngại với bạn.

Chỉnh sửa - Các áp phích khác đã đề cập đến Nguyên tắc chịu trách nhiệm một lần. Mặc dù đây là một hướng dẫn tốt, cá nhân tôi nghĩ rằng nó đi xa hơn điều này. Ngay cả một số đoạn mã có một trách nhiệm được xác định rõ ràng cũng có thể bị phân hủy để tái sử dụng và dễ đọc.

Answer 2

Triết lý của tôi là chia nhỏ mã thành đơn vị nguyên tử, hợp lý của công việc. Một cái gì đó tôi thường có thể cung cấp cho một tên để - và sau đó tôi đặt công việc đó vào một phương pháp và cung cấp cho nó tên đó.

Answer 3

Tôi nghĩ phần quan trọng nhất của việc chia nhỏ mã là Single Responsibility Principle (SRP). Mọi đối tượng phải có trách nhiệm duy nhất và trách nhiệm đó phải được đóng gói hoàn toàn theo lớp

Answer 4

Quy tắc chung là Single Responsibility Principle. Mỗi đơn vị mã phải chịu trách nhiệm chính xác một điều. Điều đó áp dụng cho các phương thức cũng như các lớp học. Nếu bạn có thể đặt một tên ngắn gọn, đơn giản cho mỗi phương thức riêng tư của bạn là cho thì sẽ ổn. Nếu bạn chỉ có thể mô tả nó là "một phần của" một hoạt động lớn hơn, thì nó có lẽ không nên là một phương pháp riêng biệt.

Nhưng từ câu hỏi của bạn, có vẻ như bạn đang thực hiện nó ngay bây giờ.

Answer 5

Quy tắc chung của tôi là nếu một chức năng không vừa trên một màn hình đơn (nghĩ một dòng 24 cũ bằng 80 cột cuối cùng), tốt hơn là một lý do chính đáng. Đôi khi có.Bạn phải ghi nhớ rằng nói chung, bất cứ ai đọc chức năng của bạn đều phải hiểu toàn bộ sự việc. Khi nó dài, đó là khó khăn hơn để làm.

Điều đó đang được nói, hai hoặc ba chức năng của đường không thêm nhiều. Họ thường tự mình dễ hiểu và tên mà bạn cung cấp cho họ sẽ không truyền tải nhiều thông tin như chính mã khi được nhúng vào một số chức năng dài hơn.

Luôn có ngoại lệ. Không có cách nào RIGHT. Công việc của bạn sẽ cải thiện với kinh nghiệm.