Các phương thức trợ giúp riêng so với các phương thức tiện ích tĩnh công cộng trong Java

Question

Tôi có một lớp Java đang trở nên dài. Khi tôi chạy nó thông qua các công cụ chất lượng mã, tôi bị gắn cờ cho số dòng trong lớp.

Đây là lớp lớp thấp hơn, được sử dụng bởi các lớp trên cùng với Spring's@Autowired. Lớp này có rất nhiều phương thức cá thể riêng không phải là tĩnh. Chúng không sử dụng bất kỳ trường instance nào, chỉ làm việc trên các tham số của phương thức.

Tôi có thể di chuyển an toàn các phương thức này dưới dạng public static trong một số lớp tiện ích riêng biệt không? Nhược điểm là gì?

Answer 1

Tư duy "sai" ở đây.

Bạn không làm lại lớp học của mình vì các công cụ đang phàn nàn về điều này hoặc điều đó.

Bạn muốn cải thiện chất lượng mã nguồn của bạn; và các công cụ như vậy có thể giúp xác định "chủ đề đáng suy nghĩ suy nghĩ". Bạn lấy phản hồi của họ làm gợi ý; không phải là "thứ tự".

Vì vậy, bạn không phải lo lắng về "dòng mã" trong một lớp học. Thay vào đó, bạn lo lắng về các trách nhiệm mà lớp này có. Có nghĩa là: số lượng dòng không phải là vấn đề cho mỗi lần truy cập - nhưng vi phạm của Single Responsibility Principle là.

Do đó: bạn quay lại và xem chính xác lớp học của bạn đang làm gì. Và khi nó rõ ràng đang làm nhiều hơn một điều, bạn trích xuất các khía cạnh như vậy vào các lớp khác!

Có nghĩa là: nếu bạn thực sự thấy rằng tất cả mã này "thuộc về" trách nhiệm của lớp đó; sau đó giữ nó trong đó. Không bắt đầu đặt chi tiết triển khai nội bộ vào các lớp trợ giúp không liên quan; chỉ vì một số công cụ cảnh báo bạn về số lượng các dòng.

Mặt khác, chuyển các phương thức riêng thành thành phần tĩnh/gói được bảo vệ sẽ cho phép bạn kiểm tra đơn vị những phương pháp đó. Đó có thể là một lợi thế. Nhưng như đã nói: miễn là chúng ta đang nói về chi tiết thực hiện , chúng phải ở chế độ riêng tư; và họ không nên được kiểm tra đơn vị.

Mã câu chuyện dài: biết và hiểu "mã sạch" là gì; và cố gắng làm theo những ý tưởng được nêu ở đó.

Answer 2

Việc chia các phương thức phải theo mục đích/ứng dụng/logic (bạn đặt tên cho nó), không phải bởi các thuộc tính kỹ thuật.

Mã nguồn dài có thể được chia thành nhiều lớp kích thước nhỏ, mỗi lớp có mục đích/trách nhiệm riêng biệt.

Answer 3

Tôi liên tục sử dụng các lớp Utility có chứa các phương thức tĩnh và thấy nó rất tiện lợi. Nếu các phương thức này thực sự được sử dụng bởi một lớp duy nhất, bạn chỉ có thể đặt lớp Utility của bạn là lớp riêng tĩnh trong lớp ban đầu của bạn. Nhưng tôi phát hiện ra rằng trong nhiều trường hợp, các phương thức tiện ích tĩnh chung có thể được sử dụng bởi nhiều lớp, vì vậy trong trường hợp này, tôi tạo một lớp tiện ích riêng biệt với các phương thức tĩnh có thể được sử dụng bởi một số lớp.

Ngoài ra, tôi mạnh mẽ đồng ý với câu trả lời của GhostCat về cách suy nghĩ chung. Đối với kích thước của một lớp học - nó có thể là một mối quan tâm nhưng thường tôi không lo lắng về điều đó nhiều. Những gì tôi thực sự tìm kiếm là kích thước của các phương pháp của bạn.Tôi thích các phương thức ngắn gọn và tự giải thích, bắt đầu với tên của nó và các tên tham số và thứ tự và logic. Nếu có phần lớn của logic nội bộ - hãy trích xuất nó thành phương pháp riêng biệt. Điều đó làm cho mã dễ đọc hơn và dễ bảo trì hơn.

Answer 4

Không thể đo lường chất lượng mã theo số dòng. Nếu bạn thấy rằng tệp lớp học đang phát triển từng ngày, hãy đảm bảo lớp học của bạn tuân theo Nguyên tắc về trách nhiệm duy nhất.

Khi lớp học của bạn không tuân theo nguyên tắc, hãy tách chúng thành các lớp riêng lẻ và biến lớp học thành một gói.

Khác bạn có thể đặt lớp cơ sở là abstract class và thực hiện các phương thức util của mình là abstract. Có một lớp con mở rộng lớp cơ sở cung cấp việc triển khai thực hiện các phương thức trừu tượng trong lớp cơ sở.

Đây là một tốt SO answer on when you could make your methods as static

Như đã nói bởi @Zack Jannsen,

"tĩnh" thường là có giá trị khi bạn biết điều gì đó sẽ không thay đổi qua trường. Nếu đúng như vậy, tôi thực sự sẽ xem xét "Nguyên tắc Trách nhiệm ", ngụ ý rằng một lớp học nên có một trách nhiệm và do đó chỉ có một lý do để thay đổi. Tôi cảm thấy một nên xem xét di chuyển các "ConvertMpgToKpl (double mpg)" chức năng, và phương pháp tương tự, đến lớp học của riêng mình. Mục đích của một đối tượng xe hơi là cho phép khởi tạo ô tô, không cung cấp sự so sánh giữa chúng. Những thứ đó phải ở bên ngoài lớp học.

Mặc dù tĩnh cho phép bạn truy cập vào phương pháp mà không cần tạo đối tượng, luôn luôn ghi nhớ những điều sau khi cố gắng để làm phương pháp như tĩnh

• Phương pháp này tạo ra kết quả phù hợp dựa trên những lập luận đầu vào
• Bạn luôn luôn cần phương pháp đó để có trong bộ nhớ (tức là, bạn cần phương pháp khá thường xuyên) - Có thể tốt hơn để truy cập một phương pháp rất lớn mà chỉ được truy cập một vài lần với sự trợ giúp của việc tạo đối tượng thay vì truy cập nó qua static
• Các phương pháp hữu ích được sử dụng khá thường xuyên có thể được thực hiện dưới dạng static