@Nonnull ile ek açıklamalı parametreleri boş olarak kontrol edilsin mi?

FindBugs'ı kullanmaya ve parametrelerimize @Nonnulluygun şekilde açıklama eklemeye başladık ve döngüdeki hataları belirtmek harika çalışıyor. Şimdiye kadar nullGuava'ları kullanmak için bu argümanları kontrol etmeye devam ettik checkNotNull, ancak nulldeğerin kontrol edilmeden null, örneğin bir SOAP isteği olmadan girilebileceği yerlerde sadece kenarlarda kontrol etmeyi tercih ederim .

// service layer accessible from outside
public Person createPerson(@CheckForNull String name) {
    return new Person(Preconditions.checkNotNull(name));
}

...

// internal constructor accessed only by the service layer
public Person(@Nonnull String name) {
    this.name = Preconditions.checkNotNull(name);  // remove this check?
}

Bunun değerlerin kendisini @Nonnullengellemediğini anlıyorum null.

Bununla birlikte, FindBugs'ın bir değerin işaretlenmemiş bir alandan işaretli bir alana aktarıldığı herhangi bir yere işaret edeceği göz önüne alındığında, @Nonnullbu değerleri, nullgeçtikleri her yer için kontrol etmek zorunda kalmadan bu vakaları (ki) yakalamak için ona güvenemeyiz mi? sistem? Araca güvenmek ve bu ayrıntılı denetimlerden kaçınmak istiyorum naif miyim?

Alt satır:null Aşağıdaki ikinci kontrolü kaldırmak güvenli gibi görünse de , kötü bir uygulama mı?

Bu soru belki de null beklemiyorsa null olup olmadığını kontrol etmeli , ancak özellikle @Nonnullek açıklama ile ilgili soruyorum .

FindBug'a güvenmiyorsanız, bir iddia kullanmak bir seçenek olabilir. Bu şekilde, Kullanıcı MSalters tarafından belirtilen sorunlardan kaçınırsınız, ancak yine de bir denetiminiz olur. Tabii ki, böyle bir başarısızlık hızlı yaklaşım mümkün değilse, bu yaklaşım geçerli olmayabilir, yani herhangi bir istisna yakalamanız gerekir.

Ve kötü uygulama olup olmadığı sorusunu daha fazla cevaplamak. Bu tartışmalı ama öyle düşünmezdim. Bu FindBug ek açıklamasını sözleşme ilkesine göre tasarımı takip eden hafif bir özellik olarak görüyorum.

Sözleşmeyle tasarımda, bir yöntem ve arayanı arasında bir sözleşme oluşturursunuz. Sözleşme, arayanın yöntemi çağırırken yerine getirmeyi kabul ettiği ön koşullardan ve ön koşulu yerine getirilirse, yürütme sonrasında yöntem tarafından yerine getirilen bir son koşuldan oluşur.

Bu geliştirme yönteminin avantajlarından biri, tüm geçersiz parametre değerlerini açıkça kontrol ettiğiniz vb. Bunun yerine sözleşmeye güvenebilir ve performansı ve okunabilirliği artırmak için gereksiz denetimlerden kaçınabilirsiniz.

Sözleşmeler, bir sözleşme bozulduğunda programınızın başarısız olmasını istediğiniz, yukarıda belirtilen başarısız ilk ilkesini izleyen çalışma zamanı onaylama denetimi için kullanılabilir ve size hata kaynağını tanımlamanız için bir ipucu verir. (Başarısız bir ön koşul, arayanın yanlış bir şey yaptığı anlamına gelir, başarısız bir son koşul, verilen yöntemin bir uygulama hatasını gösterir)

Dahası, sözleşmeler, kaynak kodu hakkında gerçekten çalıştırmadan sonuçlar çıkarmaya çalışan statik analiz için kullanılabilir.

@Nonnull ek açıklaması, FindBugs aracı tarafından statik analiz için kullanılan bir ön koşul olarak görülebilir. Çalışma zamanı onaylama denetimi, yani başarısız ilk stratejisi gibi bir yaklaşımı tercih ederseniz, onaylama ifadelerini yerleşik Java olarak kullanmayı düşünmelisiniz. Ya da Java Modelleme Dili (JML) gibi bir davranışsal arayüz belirtim dili kullanarak daha karmaşık bir belirtim stratejisine uyum sağlamak.

JML, spesifikasyonun özel Java Yorumlarına gömüldüğü Java'nın bir uzantısıdır. Bu yaklaşımın bir avantajı, uygulama ayrıntılarından ziyade yalnızca spesifikasyona güvendiğiniz ve belirtilen çalışma zamanı onaylama kontrol araçları gibi spesifikasyondan faydalanan farklı araçlar kullandığınız bir geliştirme yaklaşımı kullanarak bile gelişmiş spesifikasyonu kullanabilmenizdir. otomatik birim testleri veya dokümantasyon üretimi.

@Nonnull'un (hafif) bir sözleşme olduğu yönündeki görüşümü paylaşırsanız, ek kontroller eklememek yaygın bir uygulama olacaktır çünkü bu prensibin arkasındaki orijinal fikir savunma programlamasından kaçınmaktır.

Neden yazmadığınızı düşünün

this.name = Preconditions.checkNotNull(name);  // Might be necessary
that.name = Preconditions.checkNotNull(this.name);  // Who knows?

Programlama kara büyü değil. Değişkenler aniden Null olmaz. Eğer bir değişken boş olmadığını biliyorum ve bunu değişmedi biliyorum, o zaman do not kontrol edin.

Bunu kontrol ederseniz, gelecekte bazı programcılar (muhtemelen siz) bu kontrolün neden orada olduğunu bulmak için çok zaman harcayacaklar. Ne de olsa kontrol bir sebepten ötürü orada olmalı, o zaman ne görüyorsunuz?