Java'nın somut jeneriklere sahip olmamasını neden umursayayım?

Bu, geçenlerde bir röportajda sorduğum bir soru olarak adayın Java diline eklenmesini görmek istediği bir şey olarak ortaya çıktı. Genellikle Java'nın jenerikleri somutlaştırmadığı bir acı olarak tanımlanır , ancak zorlandığında, aday bana orada olsaydı başarabileceği türden şeyleri söyleyemezdi.

Açıktır ki, Java'da ham türlere (ve güvenli olmayan kontrollerde) izin verildiği için, jenerikleri List<Integer>tersine çevirmek ve (örneğin) gerçekten Strings içeren bir sonuç elde etmek mümkündür . Tip bilgisi somutlaştırıldığında bu açıkça imkansız hale getirilebilirdi; ama bundan daha fazlası olmalı !

İnsanlar , gerçekleştirilmiş jenerikler mevcutsa, gerçekten yapmak isteyecekleri şeylerin örneklerini gönderebilirler mi? Demek istediğim, açıkçası Listçalışma zamanında a türünü alabilirsiniz - ama bununla ne yapardınız?

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

DÜZENLEME : Yanıtlar temelde Classbir parametre olarak bir parametre olarak geçme ihtiyacı hakkında endişeli göründüğü için buna hızlı bir güncelleme (örneğin EnumSet.noneOf(TimeUnit.class)). Bunun mümkün olmadığı bir yerde daha fazlasını arıyordum . Örneğin:

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

Bu "ihtiyaç" ile karşılaştığım birkaç zamandan beri, nihayetinde bu yapıya indirgeniyor:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

Bu, C # 'da çalışır, Tbunun bir varsayılan . Çalışma zamanı türünü bile typeof(T)alabilir ve yapıcıları ile alabilirsiniz Type.GetConstructor().

Ortak Java çözümü Class<T>, argüman olarak geçmek olacaktır .

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

(Yapıcı argüman olarak iletilmesi gerekmez, çünkü bir yöntem argümanı da iyidir, yukarıdakiler sadece bir örnektir, ayrıca try-catchkısalık için ihmal edilmiştir)

Diğer tüm genel tip yapılar için, gerçek tip, biraz yansıma yardımı ile kolayca çözülebilir. Aşağıdaki Soru-Cevap, kullanım durumlarını ve olasılıkları göstermektedir:

• Java.util.List'in genel türünü alın
• Çalışma zamanında genel tür nasıl elde edilir?
• Soyut üst sınıfta gerçek türdeki genel tür bağımsız değişkenini alın

Beni en çok ısıran şey, birden çok jenerik tipte birden çok gönderimden yararlanamamaktır. Aşağıdakiler mümkün değildir ve bunun en iyi çözüm olacağı birçok durum vardır:

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

Tip güvenliği akla geliyor. Parametreleştirilmiş bir türe geri dönüş, yeniden biçimlendirilmiş jenerikler olmadan her zaman güvenli olmayacaktır:

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

Ayrıca, soyutlamalar daha az sızıntı yapacaktır - en azından tür parametreleri hakkındaki çalışma zamanı bilgileriyle ilgilenenler. Bugün, genel parametrelerden birinin türü hakkında herhangi bir çalışma zamanı bilgisine ihtiyacınız varsa, onu da iletmelisiniz Class. Bu şekilde, harici arayüzünüz uygulamanıza bağlıdır (parametreleriniz için RTTI kullanıp kullanmamanız).

Kodunuzda genel diziler yaratabileceksiniz.

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

Bu eski bir soru, bir sürü cevap var ama bence mevcut cevaplar uygun değil.

"somutlaştırılmış" sadece gerçek anlamına gelir ve genellikle tür silme işleminin tersi anlamına gelir.

Java Generics ile ilgili en büyük sorun:

• Bu korkunç boks gereksinimi ve ilkellerle referans türleri arasındaki kopukluk. Bu, doğrudan şeyleştirme veya tür silme ile ilgili değildir. C # / Scala bunu düzeltin.
• Kendi kendine tip yok. JavaFX 8, bu nedenle "kurucuları" kaldırmak zorunda kaldı. Tip silme ile kesinlikle hiçbir ilgisi yok. Scala bunu düzeltir, C # konusunda emin değil.
• Bildirim tarafı tür farkı yok. C # 4.0 / Scala buna sahip. Tip silme ile kesinlikle hiçbir ilgisi yok.
• Aşırı yüklenemez void method(List<A> l)ve method(List<B> l). Bu, tür silme nedeniyledir ancak son derece önemsizdir.
• Çalışma zamanı türü yansıması için destek yok. Bu, tür silme işleminin kalbidir. Derleme zamanında program mantığınızın çoğunu doğrulayan ve kanıtlayan süper gelişmiş derleyicilerden hoşlanıyorsanız, mümkün olduğunca az yansıma kullanmalısınız ve bu tür silme türü sizi rahatsız etmemelidir. Daha düzensiz, betik, dinamik tip programlamayı seviyorsanız ve mantığınızın olabildiğince doğru olduğunu kanıtlayan bir derleyiciyi çok fazla önemsemiyorsanız, o zaman daha iyi yansıtma ve düzeltme tipi silme işlemi yapmak önemlidir.

Serileştirme, ödüllendirme ile daha kolay olacaktır. İstediğimiz şey

deserialize(thingy, List<Integer>.class);

Yapmamız gereken şey

deserialize(thing, new TypeReference<List<Integer>>(){});

çirkin görünüyor ve tuhaf çalışıyor.

Şöyle bir şey söylemenin gerçekten yararlı olacağı durumlar da var

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

Bu şeyler çok sık ısırmaz, ancak olduklarında ısırırlar.

Java Geneircs'e maruz kalmam oldukça sınırlıdır ve diğer yanıtların daha önce bahsettiği noktalardan ayrı olarak, Maurice Naftalin ve Philip Walder'ın Java Generics and Collections kitabında , somutlaştırılmış jeneriklerin yararlı olduğu bir senaryo açıklanmıştır .

Türler yeniden yapılandırılamadığından, Parametreli istisnalara sahip olmak mümkün değildir.

Örneğin aşağıdaki formun beyanı geçerli değildir.

class ParametericException<T> extends Exception // compile error

Bunun nedeni, catch cümlesinin, atılan istisnanın belirli bir türle eşleşip eşleşmediğini kontrol etmesidir. Bu kontrol, örnek testi tarafından gerçekleştirilen kontrol ile aynıdır ve tip yeniden tanımlanamayacağı için yukarıdaki ifade şekli geçersizdir.

Yukarıdaki kod geçerli olsaydı, aşağıdaki şekilde istisna işleme mümkün olabilirdi:

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

Kitap ayrıca, Java jeneriklerinin C ++ şablonlarının tanımlanma (genişletme) şekline benzer şekilde tanımlanması durumunda, optimizasyon için daha fazla fırsat sunduğundan daha verimli uygulamaya yol açabileceğinden bahsediyor. Ancak bundan daha fazla açıklama sunmuyor, bu yüzden bilgili kişilerden gelecek herhangi bir açıklama (işaretler) yardımcı olacaktır.

Diziler, somutlaştırılmış olsalardı muhtemelen jeneriklerle çok daha iyi oynayacaktı.

Yineleyici olarak bir jdbc sonuç kümesini sunan bir sarmalayıcım var (bu, bağımlılık enjeksiyonu yoluyla veritabanı kaynaklı işlemleri çok daha kolay bir şekilde test edebileceğim anlamına geliyor).

API Iterator<T>, T'nin yalnızca yapıcıdaki dizeler kullanılarak oluşturulabilen bir tür olduğu gibi görünür . Yineleyici daha sonra sql sorgusundan döndürülen dizelere bakar ve ardından bunu T tipi bir kurucu ile eşleştirmeye çalışır.

Mevcut jeneriklerin uygulanma biçiminde, sonuç kümemden oluşturacağım nesnelerin sınıfını da geçirmem gerekiyor. Doğru anlarsam, jenerikler somutlaştırılmış olsaydı, yapıcılarını almak için T.getClass () 'ı çağırabilirdim ve sonra çok daha düzgün olacak Class.newInstance () sonucunu kullanmak zorunda kalmazdım.

Temel olarak, API'leri yazmayı (sadece bir uygulama yazmanın aksine) daha kolay hale getirdiğini düşünüyorum çünkü nesnelerden çok daha fazlasını çıkarabilirsiniz ve bu nedenle daha az yapılandırma gerekli olacaktır ... reams of config yerine spring veya xstream gibi şeylerde kullanıldığını gördüm.

İlkel (değer) türler için kutudan kaçınmak güzel bir şey olabilir. Bu bir şekilde diğerlerinin ortaya çıkardığı dizi şikayetiyle ilgilidir ve bellek kullanımının kısıtlı olduğu durumlarda aslında önemli bir fark yaratabilir.

Parametreli tip üzerinde düşünebilmenin önemli olduğu bir çerçeve yazarken çeşitli problem türleri de vardır. Elbette bu, çalışma zamanında bir sınıf nesnesinin etrafından geçirilerek çözülebilir, ancak bu API'yi gizler ve çerçeve kullanıcısına ek bir yük getirir.

Olağanüstü bir şey elde edeceğinizden değil. Anlaması daha kolay olacak. Tür silme, yeni başlayanlar için zor bir zaman gibi görünür ve sonuçta derleyicinin çalışma şeklini anlamasını gerektirir.

Bence jenerik sade yani, ekstra gereksiz döküm kazandırıyor.

Buradaki tüm cevapların gözden kaçırdığı ve benim için sürekli baş ağrısına neden olan bir şey, türler silindiğinden, genel bir arayüzü iki kez miras alamazsınız. İnce taneli arayüzler yapmak istediğinizde bu bir problem olabilir.

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

Bugün beni yakalayan bir şey var: şeyleştirmeden, genel öğelerin bir değişken listesini kabul eden bir yöntem yazarsanız ... arayanlar, türlerinin güvenli olduğunu DÜŞÜNEBİLİR, ancak yanlışlıkla herhangi bir eski pisliğe girip yönteminizi havaya uçurabilir.

Olması olası görünmüyor mu? ... Elbette, ta ki ... siz veri türünüz olarak Class'ı kullanana kadar. Bu noktada, arayan kişi size mutlu bir şekilde çok sayıda Sınıf nesnesi gönderecektir, ancak basit bir yazım hatası size T'ye uymayan Sınıf nesneleri ve felaket grevleri gönderecektir.

(NB: Burada bir hata yapmış olabilirim, ancak "jenerik değişkenler" etrafında gezinirken, yukarıdakiler tam da beklediğiniz gibi görünüyor. Bunu pratik bir sorun yapan şey, sanırım Sınıf kullanımıdır - arayanlar görünüyor daha az dikkatli olmak için :()

Örneğin, haritalarda anahtar olarak Sınıf nesnelerini kullanan bir paradigma kullanıyorum (basit bir haritadan daha karmaşık - ama kavramsal olarak olan budur).

Örneğin, Java Generics'te harika çalışıyor (önemsiz örnek):

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

Örneğin, Java Generics'te yeniden biçimlendirme olmadan, bu HERHANGİ "Sınıf" nesnesini kabul eder. Ve bu, önceki kodun yalnızca küçük bir uzantısı:

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

Yukarıdaki yöntemler tek bir projede binlerce kez yazılmalıdır - bu nedenle insan hatası olasılığı yüksek olur. Hataları ayıklamak "eğlenceli değil" demek. Şu anda bir alternatif bulmaya çalışıyorum, ancak fazla umut vermeyin.