IDEA'nın Java için de bu denetime sahip olduğuna dikkat edin, Yöntem 'statik' olabilir ,
Bu denetim, güvenli bir şekilde statik hale getirilebilecek yöntemleri bildirir. Bir yöntem, sınıfının statik olmayan yöntemlerinden ve statik olmayan alanlarından herhangi birine başvurmazsa ve bir alt sınıfta geçersiz kılınmazsa statik olabilir ...
Ancak Java kodu için bu denetim varsayılan olarak kapalıdır (programcı kendi takdirine bağlı olarak açabilir). Bunun nedeni büyük olasılıkla bu tür bir denetimin geçerliliğine / yararlılığına birkaç oldukça yetkili kaynağa dayanarak itiraz edilebilir.
Başlangıç olarak, resmi Java öğreticisi yöntemlerin ne zaman statik olması gerektiği konusunda oldukça kısıtlayıcıdır:
Statik yöntemler için yaygın bir kullanım, statik alanlara erişmektir.
Yukarıda verildiği gibi, varsayılan olarak bahsedilen denetimin açılmasının Java'da önerilen statik değiştiricinin kullanılmasına uygun olmadığı iddia edilebilir.
Ayrıca, bu teftişin arkasında yatan fikirleri kullanma ya da cesaretini kırma konusunda mantıklı bir yaklaşım öneren başka kaynaklar da var.
Örneğin, Java World makalesine bakın - Mr. Happy Object statik yöntemleri öğretir :
Örnek durumdan bağımsız herhangi bir yöntem, statik olarak bildirilmek için adaydır.
"Statik olarak ilan edilmek için aday" diyorum. Önceki örnekte bile hiçbir şey sizi instances()statik olarak bildirmeye zorlamaz. Statik olarak bildirmek, yöntemi çağırmak için bir örneğe ihtiyacınız olmadığından aramayı daha kolay hale getirir. Bazen, örnek durumuna bağlı görünmeyen yöntemleriniz olabilir. Bu yöntemleri statik yapmak istemeyebilirsiniz. Aslında, muhtemelen yalnızca örnek olmadan erişmeniz gerekiyorsa statik olarak bildirmek isteyeceksiniz.
Dahası, böyle bir yöntemi statik olarak bildirebilmenize rağmen, tasarımınıza müdahale ettiği kalıtım sorunları nedeniyle istemeyebilirsiniz. Karşılaşacağınız bazı sorunları görmek için "Etkili Nesneye Dayalı Tasarım" a göz atın ...
Google test blogundaki bir makale, Statik Yöntemlerin Ahit Edilebilirlik İçin Ölüm olduğunu iddia etmek kadar ileri gider :
Zihinsel bir egzersiz yapalım. Uygulamanızın statik yöntemlerden başka bir şey olmadığını varsayalım. (Evet, böyle bir kod yazmak mümkündür, buna prosedürel programlama denir.) Şimdi bu uygulamanın çağrı grafiğini hayal edin. Bir yaprak yöntemini çalıştırmayı denerseniz, durumunu ayarlama ve tüm köşe durumlarını iddia etme konusunda hiçbir sorununuz olmaz. Bunun nedeni, bir yaprak yönteminin başka çağrı yapmamasıdır. Yapraklardan uzaklaştıkça ve kök main()yöntemine yaklaştıkça , testinizde durumu ayarlamak zorlaşır ve bir şeyler iddia etmek zorlaşır. Birçok şeyin iddia edilmesi imkansız hale gelecektir. Testleriniz giderek büyüyecek. Bir kez ulaştığınızdamain()Artık bir birim testiniz yok (üniteniz tüm uygulama olduğu için) artık bir senaryo testiniz var. Test etmeye çalıştığınız uygulamanın bir kelime işlemci olduğunu düşünün. Ana yöntemden iddia edebileceğiniz çok şey yok ...
Bazen statik yöntemler diğer nesneler için bir fabrika olabilir. Bu, test problemini daha da şiddetlendirir. Testlerde, önemli bağımlılıkları alaylarla değiştiren nesneleri farklı şekilde kablolayabileceğimize güveniyoruz. Bir newoperatör çağrıldıktan sonra yöntemi bir alt sınıfla geçersiz kılamayız. Böyle bir statik fabrikanın arayanı, statik fabrika yönteminin ürettiği beton sınıflarına kalıcı olarak bağlıdır. Başka bir deyişle, statik yöntemin hasarı, statik yöntemin kendisinin çok ötesindedir. Nesne grafik kablolama ve yapı kodunu statik yönteme eklemek çok kötüdür, çünkü nesne grafik kablolama, işleri test etmek için şeyleri nasıl izole ettiğimizdir ...
Yukarıda verilen denetimin Java için varsayılan olarak kapalı olduğu sadece doğal görünüyor.
IDE geliştiricileri , yaygın olarak tanınan önerilere ve en iyi uygulamalara karşı varsayılan olarak ayarlamanın neden bu kadar önemli olduğunu düşündüklerini açıklamakta gerçekten zorlanacaklardı.
Groovy için işler oldukça farklı. Yukarıda listelenen argümanların hiçbiri, özellikle Javalobby'deki Groovy makalesinde Statik Yöntemleri Mocking'te açıklandığı gibi, özellikle test edilebilirlikle ilgili olanlar geçerli değildir:
Test ettiğiniz Groovy sınıfı, başka bir Groovy sınıfında statik bir yöntem çağırıyorsa, yöntemleri, yapıcıları, özellikleri ve statik yöntemleri dinamik olarak eklemenizi sağlayan ExpandoMetaClass'ı kullanabilirsiniz ...
Bu fark, büyük olasılıkla söz konusu inceleme için varsayılan ayarın Groovy'de zıt olması muhtemeldir. Java'da varsayılan "on" kullanıcı karışıklığı kaynağı olsa da, Groovy'de zıt bir ayar IDE kullanıcılarını karıştırabilir.
"Hey yöntem örnek alanları kullanmıyor, neden beni bu konuda uyarmadınız?" Bu sorunun Java için (yukarıda açıklandığı gibi) cevaplanması kolay olurdu, ancak Groovy için sadece zorlayıcı bir açıklama yoktur.