Java Koleksiyonları neden genel yöntemleri kaldırmıyor?

Neden değil Collection.remove (Object o) jenerik?

Sahip Collection<E>olabilir gibi görünüyorboolean remove(E o);

Sonra, yanlışlıkla Set<String>her bir String yerine bir ( örneğin) kaldırmaya çalıştığınızda, Collection<String>daha sonra hata ayıklama sorunu yerine derleme zamanı hatası olur.

Josh Bloch ve Bill Pugh bu konuya Java Puzzlers IV: Fantom Referans Tehdit, Klonun Saldırısı ve Vardiya İntikamı'nda değiniyor .

Josh Bloch (6:41) Harita'nın get yöntemini, yöntemi kaldırmayı ve diğer bazı yöntemleri doğrulamaya çalıştıklarını söylüyor, ancak "basitçe işe yaramadı".

Yalnızca koleksiyonun genel türüne parametre türü olarak izin verirseniz, üretilemeyen çok sayıda makul program vardır. Onun tarafından verilen örnek bir kesişimidir Listait Numbers ve Listbir Longs.

remove()(içinde Mapolduğu gibi içinde Collection) genel değildir, çünkü herhangi bir nesne türüne geçebilmeniz gerekir remove(). Kaldırılan nesnenin, ilettiğiniz nesne ile aynı tür olması gerekmez remove(); sadece eşit olmalarını gerektirir. Spesifikasyonuna kaynaktan remove(), remove(o)nesne kaldırır egibi (o==null ? e==null : o.equals(e))olduğu true. Aynı türden gerektiren ove eolmayacak bir şey olmadığını unutmayın . Bu, equals()yöntemin Objectyalnızca nesne ile aynı türde değil, bir as parametresini alması gerçeğinden kaynaklanır .

Bununla birlikte, birçok sınıfın equals(), nesnelerinin yalnızca kendi sınıfındaki nesnelere eşit olabilmesi için tanımladığı genel olarak doğru olabilir, ancak bu her zaman böyle değildir. Örneğin, için belirtim List.equals(), iki List nesnesinin hem Listeler hem de farklı uygulamaları olsa bile aynı içeriğe sahip olması durumunda eşit olduğunu belirtir List. Bu sorudaki örneğe dönersek, bir Map<ArrayList, Something>ve benim için remove()bir LinkedListargüman olarak çağırmak mümkündür ve aynı içeriğe sahip bir liste olan anahtarı kaldırmalıdır. Bu remove(), genel ve argüman türünü kısıtlamış olsaydı mümkün olmazdı .

Çünkü type parametreniz bir joker karakterse, genel bir kaldırma yöntemi kullanamazsınız.

Map 'get (Object) yöntemi ile bu soruya çalışan hatırlamak gibi görünüyor. Bu durumda get yöntemi genel değildir, ancak ilk tür parametresiyle aynı türden bir nesnenin geçirilmesini makul olarak beklemelidir. Haritalar'ı ilk tür parametresi olarak joker karakterle geçiriyorsanız, bu argümanın genel olması durumunda bu yöntemle Haritadan bir öğe almanın bir yolu olmadığını fark ettim. Joker karakter bağımsız değişkenleri gerçekten tatmin edilemez, çünkü derleyici türün doğru olduğunu garanti edemez. Eklemenin genel nedeninin, koleksiyona eklemeden önce türün doğru olduğunu garanti etmenizi beklediğiniz olduğunu tahmin ediyorum. Ancak, bir nesneyi kaldırırken, tür yanlışsa, hiçbir şeyle eşleşmez.

Muhtemelen çok iyi açıklamamıştım, ama bana yeterince mantıklı geliyor.

Diğer cevaplara ek olarak, yöntemin bir kabul etmesinin başka bir nedeni vardır Object, bu da öngörülmektedir. Aşağıdaki örneği düşünün:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

Mesele şu ki, removeyönteme iletilen nesne yöntemin tanımlanmasından sorumludur equals. Tahminler oluşturmak bu şekilde çok basitleşir.

Biri bir koleksiyona sahiptir varsayalım Catve türlerinden bazıları nesne referanslarını Animal, Cat, SiameseCat, ve Dog. Koleksiyona, Catveya SiameseCatbaşvuru tarafından belirtilen nesneyi içerip içermediğini sormak makul görünmektedir. AnimalReferans tarafından atıfta bulunulan nesneyi içerip içermediğini sormak tehlikeli görünebilir, ancak yine de tamamen makul. Sonuçta, söz konusu nesne bir a Catolabilir ve koleksiyonda görünebilir.

Ayrıca, nesne a dışında bir şey olsa bile Cat, koleksiyonda görünüp görünmediğini söylemekte bir sorun yoktur - sadece "hayır, değil" şeklinde yanıtlayın. Bir türün "arama stili" koleksiyonu, herhangi bir üst tipin referansını anlamlı bir şekilde kabul edebilmeli ve nesnenin koleksiyon içinde var olup olmadığını belirleyebilmelidir. Aktarılan nesne başvurusu ilgisiz bir türdeyse, koleksiyonun onu içerme olasılığı yoktur, bu nedenle sorgu bir anlamda anlamlı değildir (her zaman "hayır" yanıtını verecektir). Bununla birlikte, parametreleri alt türler veya üst türler ile sınırlamanın bir yolu olmadığından, herhangi bir türü kabul etmek ve türü koleksiyonun alakası olmayan nesneler için "hayır" yanıtını vermek en pratik yöntemdir.

Her zaman bunun, remove () öğesinin ne tür bir nesne verdiğinize bakmak için bir nedeni olmadığı için olduğunu düşündüm. Her ne olursa olsun, o nesnenin Koleksiyon'un içerdiklerinden biri olup olmadığını kontrol etmek yeterince kolaydır, çünkü herhangi bir şeye eşittir () diyebilir. Yalnızca bu türden nesneler içerdiğinden emin olmak için add () üzerindeki türü kontrol etmek gerekir.

Bir uzlaşma oldu. Her iki yaklaşımın da avantajları vardır:

• remove(Object o)
  • daha esnektir. Örneğin, bir sayı listesi üzerinden yineleme yapmayı ve bunları uzun listeden çıkarmayı sağlar.
  • Bu esnekliği kullanan kod daha kolay oluşturulabilir
• remove(E e) çoğu programın derleme zamanında küçük hataları algılayarak ne yapmak istediğine daha fazla tür güvenliği getirir, örneğin yanlışlıkla bir tamsayıyı şort listesinden çıkarmaya çalışmak gibi.

Java API'sini geliştirirken geriye dönük uyumluluk her zaman önemli bir hedefti, bu nedenle mevcut kodun üretilmesini kolaylaştırdığı için remove (Object o) seçildi. Geriye dönük uyumluluk bir sorun OLMADIysa, tasarımcıların kaldırmayı (E e) seçeceğini tahmin ediyorum.

Remove genel bir yöntem değildir, bu nedenle genel olmayan bir koleksiyon kullanan mevcut kod hala derlenir ve aynı davranışa sahiptir.

Ayrıntılar için http://www.ibm.com/developerworks/java/library/j-jtp01255.html adresine bakın.

Düzenleme: Bir yorumcu, ekleme yönteminin neden genel olduğunu sorar. [... açıklamam kaldırıldı ...] İkinci yorumcu firebird84'ten benden çok daha iyi bir soru yanıtladı.

Başka bir neden arabirimlerdir. İşte bunu gösteren bir örnek:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

Çünkü mevcut (Java5 öncesi) kodu kıracaktır. Örneğin,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

Şimdi yukarıdaki kodun yanlış olduğunu söyleyebilirsiniz, ancak o'nun heterojen bir nesne kümesinden geldiğini varsayalım (yani, dizeler, sayı, nesneler vb. İçeriyordu). Tüm eşleşmeleri kaldırmak istiyorsunuz, çünkü yasal değil, çünkü silme eşit olmayan dizeleri görmezden geliyordu. Ancak (String o) öğesini kaldırırsanız, bu artık çalışmaz.