Ben düşünün finalkod gürültü olmaya yöntem parametreleri ve yerel değişkenlerde. Java yöntemi bildirimleri oldukça uzun olabilir (özellikle jeneriklerle birlikte) - daha fazla yapmaya gerek yoktur.
Birim testleri düzgün yazılır Eğer nedenle, asla, "zararlı" olduğu parametrelere atama alınmayı olacak aslında bir sorun. Görme netliği, ünite testlerinizin yetersiz kapsama alanına sahip olması nedeniyle toplanmamış olası bir hatadan kaçınmaktan daha önemlidir .
Parametrelere veya yerel değişkenlere atama yapılırsa derlemeyi kırmak üzere yapılandırılabilen FindBugs ve CheckStyle gibi araçlar.
Tabii ki, onları nihai hale getirmeniz gerekiyorsa , örneğin değeri anonim bir sınıfta kullandığınız için, o zaman sorun değil - bu en basit ve en temiz çözüm.
Parametrelerinize ilave anahtar kelimeler eklemenin ve dolayısıyla IMHO'nun bunları kamufle etmenin belirgin etkisinin dışında, yöntem parametrelerine son olarak eklemek, yöntem gövdesindeki kodun daha az okunabilir olmasına neden olur, bu da kodu "daha iyi" yapmaktır mümkün olduğu kadar okunabilir ve basit olmalıdır. Kararlı bir örnek için, vakayı duyarsızca çalışması gereken bir yöntemim olduğunu söyleyin.
Olmadan final:
public void doSomething(String input) {
input = input.toLowerCase();
// do a few things with input
}
Basit. Temiz. Neler olduğunu herkes biliyor.
Şimdi 'final' ile, seçenek 1:
public void doSomething(final String input) {
final String lowercaseInput = input.toLowerCase();
// do a few things with lowercaseInput
}
Parametrelerin yapılması finalkodlayıcıyı kodun asıl değer ile çalıştığını düşünmekten daha aşağıya koyarken , kodun aşağıya kullanılması inputyerine, kullanmaması lowercaseInputgereken ve karşı korunamayacağı kadar eşit bir risk vardır. t kapsam dışına çıkarmak (hatta atamak nulliçin inputbile yine de yardımcı olacağını ise).
'Final' ile, seçenek 2:
public void doSomething(final String input) {
// do a few things with input.toLowerCase()
}
Şimdi sadece daha da fazla kod gürültüsü yarattık ve toLowerCase()n kere çağırmak zorunda kaldığımız bir performans hitini getirdik .
'Final' ile, seçenek 3:
public void doSomething(final String input) {
doSomethingPrivate(input.toLowerCase());
}
/** @throws IllegalArgumentException if input not all lower case */
private void doSomethingPrivate(final String input) {
if (!input.equals(input.toLowerCase())) {
throw new IllegalArgumentException("input not lowercase");
}
// do a few things with input
}
Kod gürültüsü hakkında konuşun. Bu bir tren kazası. Yeni bir yöntemimiz var, gerekli bir istisna bloğu var, çünkü diğer kodlar onu yanlış çağırdı. İstisna için daha fazla birim testi. Hepsi bir basit ve IMHO tercih ve zararsız, çizgi önlemek için.
Ayrıca, yöntemlerin o kadar uzun olmaması gerektiğine dair bir sorun da var; görsel olarak kolayca alamaz ve bir bakışta parametreye atama yapıldığını bilirsiniz.
Bunun bir parametreye atarsanız bunu her tercihen ilk satırı, yöntemde erken veya düz temel girdi etkin kontrol ettikten sonra yapmak iyi bir uygulama / stil sizce değiştirilmesi için bütün içinde tutarlı bir etkiye sahiptir yöntemle, yöntem. Okuyucular, herhangi bir ödevin açık olmasını (imza beyannamesi yakınında) ve tutarlı bir yerde beklemelerini bilir; bu da final eklemenin kaçınmaya çalıştığı sorunu büyük ölçüde azaltır. Aslında nadiren parametrelere atarım, ancak yaparsam bunu her zaman bir yöntemin en üstünde yaparım.
Ayrıca, finalaslında ilk bakışta göründüğü gibi sizi korumadığını da unutmayın:
public void foo(final Date date) {
date.setTime(0);
// code that uses date
}
final Parametre türü ilkel veya değişken olmadıkça sizi tamamen korumaz.