Lưu ý rằng IDEA cũng có kiểm tra này đối với Java, nó được gọi là Phương thức có thể là 'tĩnh' ,
Kiểm tra này báo cáo bất kỳ phương pháp nào có thể được thực hiện tĩnh. Một phương thức có thể là tĩnh nếu nó không tham chiếu bất kỳ phương thức không tĩnh nào và các trường không tĩnh của lớp và không bị ghi đè trong một lớp con ...
Mặc dù vậy, đối với mã Java, việc kiểm tra này bị tắt theo mặc định (lập trình viên có thể bật nó theo ý của họ). Lý do cho điều này rất có thể là tính hợp lệ / hữu ích của việc kiểm tra như vậy có thể bị thách thức, dựa trên một vài nguồn khá có thẩm quyền.
Để bắt đầu, hướng dẫn Java chính thức khá hạn chế khi các phương thức nên tĩnh:
Một cách sử dụng phổ biến cho các phương thức tĩnh là truy cập các trường tĩnh.
Ở trên, người ta có thể lập luận rằng bật theo kiểm tra được đề cập theo mặc định không tuân thủ việc sử dụng công cụ sửa đổi tĩnh được đề xuất trong Java.
Bên cạnh đó, có một vài nguồn khác đi xa như đề xuất một cách tiếp cận hợp lý về việc sử dụng các ý tưởng ẩn đằng sau sự kiểm tra này hoặc thậm chí không khuyến khích nó.
Xem ví dụ bài viết Thế giới Java - Ông Happy Object dạy các phương thức tĩnh :
Bất kỳ phương thức nào độc lập với trạng thái cá thể là một ứng cử viên để được khai báo là tĩnh.
Lưu ý rằng tôi nói "ứng cử viên được tuyên bố là tĩnh." Ngay cả trong ví dụ trước, không có gì buộc bạn phải khai báo instances()là tĩnh. Khai báo nó dưới dạng tĩnh chỉ giúp gọi điện thuận tiện hơn vì bạn không cần một thể hiện để gọi phương thức. Đôi khi bạn sẽ có các phương thức dường như không dựa vào trạng thái cá thể. Bạn có thể không muốn làm cho các phương thức này tĩnh. Trong thực tế, có lẽ bạn sẽ chỉ muốn khai báo chúng là tĩnh nếu bạn cần truy cập chúng mà không cần một ví dụ.
Hơn nữa, mặc dù bạn có thể khai báo một phương thức như là tĩnh, nhưng bạn có thể không muốn vì các vấn đề kế thừa mà nó xen vào thiết kế của bạn. Hãy xem "Thiết kế hướng đối tượng hiệu quả" để thấy một số vấn đề mà bạn sẽ gặp phải ...
Một bài viết tại blog thử nghiệm của Google thậm chí còn đi xa tới mức tuyên bố Phương thức tĩnh là Cái chết đối với Khả năng kiểm tra :
Hãy làm một bài tập tinh thần. Giả sử ứng dụng của bạn không có gì ngoài các phương thức tĩnh. (Có, mã như thế có thể viết, nó được gọi là lập trình thủ tục.) Bây giờ hãy tưởng tượng biểu đồ cuộc gọi của ứng dụng đó. Nếu bạn cố gắng thực hiện một phương thức lá, bạn sẽ không gặp vấn đề gì khi thiết lập trạng thái của nó và khẳng định tất cả các trường hợp góc. Lý do là một phương pháp lá không thực hiện thêm các cuộc gọi. Khi bạn di chuyển ra xa khỏi lá và càng gần main()phương pháp gốc , sẽ càng khó hơn để thiết lập trạng thái trong bài kiểm tra của bạn và khó hơn để khẳng định mọi thứ. Nhiều thứ sẽ trở nên không thể khẳng định. Các bài kiểm tra của bạn sẽ ngày càng lớn hơn. Một khi bạn đạt đếnmain()phương pháp bạn không còn có bài kiểm tra đơn vị (vì đơn vị của bạn là toàn bộ ứng dụng) bây giờ bạn có bài kiểm tra kịch bản. Hãy tưởng tượng rằng ứng dụng bạn đang cố kiểm tra là một trình xử lý văn bản. Không có nhiều thứ bạn có thể khẳng định từ phương thức chính ...
Đôi khi một phương thức tĩnh là một nhà máy cho các đối tượng khác. Điều này càng làm tăng thêm vấn đề thử nghiệm. Trong các thử nghiệm, chúng tôi dựa vào thực tế là chúng ta có thể nối các vật thể khác nhau thay thế các phụ thuộc quan trọng bằng các giả. Khi một newtoán tử được gọi, chúng ta không thể ghi đè phương thức với một lớp con. Một người gọi của một nhà máy tĩnh như vậy bị ràng buộc vĩnh viễn với các lớp cụ thể mà phương thức nhà máy tĩnh tạo ra. Nói cách khác, thiệt hại của phương thức tĩnh vượt xa chính phương thức tĩnh. Kết nối dây biểu đồ đối tượng và mã xây dựng vào phương thức tĩnh là cực kỳ xấu, vì nối dây biểu đồ đối tượng là cách chúng ta cô lập mọi thứ để thử nghiệm ...
Bạn thấy, được đưa ra ở trên có vẻ tự nhiên rằng kiểm tra được đề cập bị tắt theo mặc định cho Java.
Các nhà phát triển IDE sẽ có một thời gian thực sự khó khăn để giải thích lý do tại sao họ nghĩ rằng nó rất quan trọng để đặt nó theo mặc định, chống lại các khuyến nghị được công nhận rộng rãi và thực tiễn tốt nhất.
Đối với Groovy, mọi thứ hoàn toàn khác. Không có đối số nào được liệt kê ở trên áp dụng, đặc biệt là đối số về khả năng kiểm tra, như được giải thích, ví dụ như trong Mocking Phương thức tĩnh trong bài viết Groovy tại Javalulk:
Nếu lớp Groovy mà bạn đang kiểm tra thực hiện gọi một phương thức tĩnh trên một lớp Groovy khác, thì bạn có thể sử dụng ExpandoMetaClass cho phép bạn tự động thêm các phương thức, hàm tạo, thuộc tính và phương thức tĩnh ...
Sự khác biệt này có thể là lý do tại sao cài đặt mặc định cho kiểm tra được đề cập ngược lại trong Groovy. Mặc dù trong Java mặc định "bật" sẽ là nguồn gây nhầm lẫn cho người dùng, nhưng trong Groovy, một cài đặt ngược lại có thể gây nhầm lẫn cho người dùng IDE.
"Này phương thức không sử dụng các trường mẫu, tại sao bạn không cảnh báo tôi về nó?" Câu hỏi đó sẽ dễ trả lời cho Java (như đã giải thích ở trên), nhưng đối với Groovy, không có lời giải thích thuyết phục nào.