Özellik olarak Java 8 varsayılan yöntemleri: güvenli mi?

Java 8'de özelliklerin fakirlerin erkek versiyonu olarak varsayılan yöntemleri kullanmak güvenli bir uygulama mı?

Bazıları pandaları sadece uğruna kullanırsanız üzüleceğini iddia ediyor , çünkü bu harika, ama niyetim bu değil. Ayrıca, varsayılan yöntemlerin API evrimini ve geriye dönük uyumluluğu desteklemek için tanıtıldığı da sık sık hatırlatılır, ki bu doğrudur, ancak bu onları kendi başına özellikler olarak kullanmayı yanlış veya çarpıtmaz yapmaz.

Ben şu pratik kullanım durumunda akılda:

public interface Loggable {
    default Logger logger() {
        return LoggerFactory.getLogger(this.getClass());
    }
}

Ya da belki bir tanımlayın PeriodTrait:

public interface PeriodeTrait {
    Date getStartDate();
    Date getEndDate();
    default isValid(Date atDate) {
        ...
    }
}

Kabul edilebilir bir şekilde, kompozisyon (hatta yardımcı sınıflar) kullanılabilir, ancak daha ayrıntılı ve dağınık görünür ve polimorfizmden yararlanmaya izin vermez.

Öyleyse, varsayılan yöntemleri temel özellikler olarak kullanmak uygun / güvenli mi yoksa öngörülemeyen yan etkiler konusunda endişelenmeli miyim?

SO ile ilgili birkaç soru Java ve Scala özellikleriyle ilgilidir; buradaki nokta bu değil. Ben de sadece fikir istemiyorum. Bunun yerine, yetkili bir cevap veya en azından alan bilgisi arıyorum: kurumsal projenizde özellikler olarak varsayılan yöntemleri kullandıysanız, bunun bir zaman bombası olduğu ortaya çıktı mı?

Kısa cevap: eğer onları güvenle kullanırsanız güvenlidir :)

Snarky cevap: söyle sen özelliklerin demek ve belki Sana daha iyi bir cevap vereceğiz :)

Tüm ciddiyetle, "özellik" terimi iyi tanımlanmamıştır. Çoğu Java geliştiricisi, Scala'da ifade edildiği şekliyle özelliklere en çok aşinadır, ancak Scala, isim veya fiili olarak niteliklere sahip ilk dilden uzaktır.

Örneğin, Scala'da özellikler durum bilgilidir ( vardeğişkenlere sahip olabilir ); Fortress'te saf davranışlardır. Java'nın varsayılan yöntemlere sahip arabirimleri durumsuzdur; bu onların özellik olmadığı anlamına mı geliyor? (İpucu: bu hileli bir soruydu.)

Yine Scala'da özellikler doğrusallaştırma yoluyla oluşturulur; sınıf eğer Aözellikleri uzanır Xve Y, hangi ardından sırası Xile Yarasındaki çatışmaları nasıl belirler karıştırılır Xve Yçözülür. Java'da, bu doğrusallaştırma mekanizması mevcut değildir (kısmen "Java'ya benzemediği için reddedilmiştir.)

Arayüzlere varsayılan yöntemler eklemenin en yakın nedeni arayüz gelişimini desteklemekti , ancak bunun ötesine geçtiğimizin de farkındaydık. Bunun "arayüz evrimi ++" veya "özellikler -" olduğunu düşünmeniz, kişisel bir yorumlama meselesidir. Bu nedenle, güvenlik hakkındaki sorunuza cevap vermek için ... mekanizmanın desteklemediği bir şeye isteyerek esnetmeye çalışmak yerine, aslında neyi desteklediğine bağlı kaldığınız sürece, iyi olmalısınız.

Temel tasarım hedeflerinden biri , bir arayüzün istemcisinin bakış açısından , varsayılan yöntemlerin "normal" arayüz yöntemlerinden ayırt edilemez olması gerektiğiydi. Bir yöntemin öntanımlılığı, bu nedenle, sadece arayüzün tasarımcısı ve uygulayıcısı için ilginçtir .

Tasarım hedeflerine uygun olan bazı kullanım durumları şunlardır:

• Arayüz gelişimi. Burada, mevcut bir arayüze, o arayüzdeki mevcut metotlar açısından mantıklı bir varsayılan uygulamaya sahip olan yeni bir metot ekliyoruz. Bir örnek , varsayılan uygulamanın yöntem açısından yazıldığı forEachyöntemin eklenmesi olabilir . Collectioniterator()

• "İsteğe bağlı" yöntemler. Burada, bir arayüzün tasarımcısı, "Uygulayıcıların, gerektirdiği işlevsellik sınırlamalarıyla yaşamak istiyorlarsa, bu yöntemi uygulamalarına gerek yoktur" diyor. Örneğin, Iterator.removeatan bir varsayılan verildi UnsupportedOperationException; uygulamalarının büyük çoğunluğu Iteratorzaten bu davranışa sahip olduğundan, varsayılan yöntem bu yöntemi esasen isteğe bağlı kılar. (Davranış AbstractCollectionvarsayılan olarak ifade edilmişse, Collectionaynı şeyi mutatif yöntemler için yapabiliriz.)

• Kolaylık yöntemleri. Bunlar, kesinlikle kolaylık sağlamak için olan, yine genellikle sınıfta varsayılan olmayan yöntemler açısından uygulanan yöntemlerdir. logger()İlk örnekteki yöntem bu makul bir resmidir.

• Combinators. Bunlar, mevcut örneğe dayalı olarak arabirimin yeni örneklerini somutlaştıran bileşimsel yöntemlerdir. Örneğin, yöntemler Predicate.and()veya Comparator.thenComparing()birleştiricilerin örnekleridir.

Varsayılan bir uygulama sağlarsanız, @implSpecuygulayıcıların yöntemi geçersiz kılmak isteyip istemediklerini anlamalarına yardımcı olmak için varsayılan için bazı belirtimler de sağlamalısınız (JDK'da bunun için javadoc etiketini kullanıyoruz ). Kolaylık yöntemleri ve birleştiriciler gibi bazı varsayılanlar neredeyse hiçbir zaman geçersiz kılınmaz; diğerleri, isteğe bağlı yöntemler gibi, genellikle geçersiz kılınır. Varsayılanın ne yapmayı vaat ettiği hakkında yeterli spesifikasyon (yalnızca dokümantasyon değil) sağlamanız gerekir, böylece uygulayıcı bunu geçersiz kılmak gerekip gerekmediğine dair mantıklı bir karar verebilir.