Java 8 neden değişmez koleksiyonlar içermiyor?

Java ekibi, Java 8'deki işlevsel programlamanın önündeki engelleri kaldırarak bir sürü harika çalışma yaptı. Özellikle, java.util Collections'taki değişiklikler, çok hızlı akış işlemlerine dönüştürülmesi için büyük bir zincirleme işi yapıyor. Koleksiyonlara birinci sınıf işlevler ve fonksiyonel yöntemler ekleyerek ne kadar iyi yaptıklarını göz önünde bulundurarak, neden değişmez koleksiyonlar ve hatta değişmez koleksiyon arayüzleri sağlayamıyorlar?

Var olan herhangi bir kodu değiştirmeden, Java ekibi herhangi bir zamanda değiştirilebilir olanlarla aynı olan değişken arayüzleri ekleyebilir, "set" yöntemlerini eksi ekleyebilir ve mevcut arayüzlerin bunlardan genişlemesini sağlayabilir:

                  ImmutableIterable
     ____________/       |
    /                    |
Iterable        ImmutableCollection
   |    _______/    /          \   \___________
   |   /           /            \              \
 Collection  ImmutableList  ImmutableSet  ImmutableMap  ...
    \  \  \_________|______________|__________   |
     \  \___________|____________  |          \  |
      \___________  |            \ |           \ |
                  List            Set           Map ...

Tabii, List.add () ve Map.put () gibi işlemler, işlemin başarılı veya başarısız olduğunu belirtmek için şu anda verilen anahtar için bir boolean veya önceki değer döndürüyor. Değiştirilemez koleksiyonların fabrikalar gibi yöntemleri ele alması ve mevcut imzayla uyumlu olmayan eklenen öğeyi içeren yeni bir toplama yapması gerekir. Ancak bu, ImmutableList.append () veya .addAt () ve ImmutableMap.putEntry () gibi farklı bir yöntem adı kullanarak çözülebilir. Sonuçta ortaya çıkan ayrıntılılık, değişmeyen koleksiyonlarla çalışmanın yararlarından daha ağır basacak ve tip sistemi yanlış yöntemi arama hatalarını önleyecektir. Zamanla, eski yöntemler kullanımdan kaldırılabilir.

Değişmez koleksiyonların kazancı:

• Basitlik - temel verinin değişmediği durumlarda kod hakkında muhakeme daha basittir.
• Belgeleme - Bir yöntem değişmez bir koleksiyon arayüzüne sahipse, bu koleksiyonu değiştirmeyeceğini bilirsiniz. Bir yöntem değişmez bir koleksiyon döndürürse, onu değiştiremeyeceğinizi bilirsiniz.
• Eşzamanlılık - değişmeyen koleksiyonlar iş parçacıkları arasında güvenle paylaşılabilir.

Değişmezliği kabul eden dilleri tadayan biri olarak, yaygın mutasyona uğramış vahşi batıya dönmek çok zordur. Clojure'un koleksiyonları (dizi soyutlaması) zaten Java 8 koleksiyonlarının sağladığı her şeye, artı değişkenliğe (akışlar yerine senkronize bağlı listeler nedeniyle ek bellek ve zaman kullanıyor olsa da) zaten sahip. Scala, tam bir işlem setiyle hem değişken hem de değişmeyen koleksiyonlara sahiptir ve bu işlemler istekli olsa da, .iterator'ı tembel bir görünüm verir (ve bunları tembel olarak değerlendirmenin başka yolları da vardır). Java'nın, değişmeyen koleksiyonlar olmadan nasıl rekabet etmeye devam edebileceğini anlamıyorum.

Birisi beni bu konuda tarih veya tartışmalara yönlendirebilir mi? Kesinlikle bir yerlerde halka açık.

Çünkü değişmez koleksiyonlar kesinlikle kullanılabilir olmalarını gerektirir. Aksi halde, her bir işlem başka bir listeyi bir yere yığar. Haskell gibi tamamen değişmeyen diller, agresif optimizasyonlar ve paylaşımlar olmadan şaşırtıcı miktarda çöp üretir. Sadece <50 element ile kullanılabilen koleksiyona sahip olmak standart kütüphaneye koymaya değmez.

Dahası, değişmez koleksiyonlar genellikle değişebilir meslektaşlarından temelde farklı uygulamalara sahiptir. Örneğin düşünün ArrayList, verimli bir değişken ArrayListhiç bir dizi olmaz! Büyük bir dallanma faktörüne sahip dengeli bir ağaç ile uygulanmalıdır, Clojure 32 IIRC kullanır. Değişken koleksiyonları yalnızca işlevsel bir güncelleme ekleyerek "değiştirilemez" yapmak, bir bellek sızıntısı kadar olduğu gibi bir performans hatasıdır.

Ayrıca, paylaşım Java'da geçerli değildir. Java, paylaşımı "sadece bir optimizasyon" yapmak için değişkenlik ve referans eşitliği için çok sayıda sınırsız kanca sağlar. Listedeki bir öğeyi değiştirebilseniz ve sahip olduğunuz listenin diğer 20 sürümünde bir öğeyi değiştirdiğinizi fark ederseniz, muhtemelen biraz üzülecektir.

Bu aynı zamanda, verimli değişmezlik, paylaşım, akış füzyonu için çok önemli optimizasyon sınıflarını da dışlar, mutasyona uğrarsanız, değişkenlik bozar. (Bu FP evangelistleri için iyi bir slogan olur)

Değişken bir koleksiyon değişmez bir koleksiyonun alt türü değildir. Bunun yerine, değişken ve değişken koleksiyonlar, okunabilir koleksiyonların kardeşleridir. Ne yazık ki, "okunabilir", "salt okunur" ve "değişmez" kavramları, üç farklı anlama gelmelerine rağmen birlikte bulanık görünüyor.

• Okunabilir bir koleksiyon baz sınıfı veya arayüz tipi, bir kişinin öğeleri okuyabileceğini vaat eder ve koleksiyonun değiştirilmesi için herhangi bir doğrudan yol sağlamaz, ancak referansı alan kodun, modifikasyona izin verecek şekilde döküm yapıp işleyemeyeceğini garanti etmez.

• Salt okunur bir koleksiyon arabirimi, yeni üyeler içermez, ancak yalnızca bir başvuruyu, koleksiyonu mutasyona uğratmak veya bir şeye referans almak gibi bir biçimde manipüle etmenin bir yolu olmadığını vaat eden bir sınıf tarafından gerçekleştirilmelidir. bu yapabilirdi. Bununla birlikte, koleksiyonun iç kısımlara referans olan başka bir şey tarafından değiştirilmeyeceğine söz vermez. Salt okunur bir koleksiyon arabiriminin, değişken sınıflar tarafından uygulanmasını önleyemeyebileceğini, ancak mutasyona izin veren herhangi bir uygulamanın veya bir uygulamadan türetilen bir sınıfın, bir uygulamanın "meşru olmayan" bir uygulaması veya türevi olarak değerlendirileceğini belirtebilir. .

• Değişmez bir koleksiyon, herhangi bir referans mevcut olduğu sürece daima aynı verileri tutacak bir koleksiyondur. Belirli bir talebe cevap olarak her zaman aynı verileri döndürmeyen değişmez bir arayüzün herhangi bir uygulaması bozulur.

Kuvvetle ilişkili değişken ve değişmez toplama uygulamak veya aynı "okunabilir" türünden türetmek ve okunabilir tip hem türlerini içerir bazen faydalıdır AsImmutable, AsMutableve AsNewMutableyöntemleri. Böyle bir tasarım, bir koleksiyondaki verileri çağırmak için devam etmek isteyen kodlara izin verebilir AsImmutable; Bu yöntem, koleksiyonun değişebilir olması durumunda savunma kopyası oluşturur, ancak zaten değiştirilemezse kopyayı atlar.

Java Collections Framework, java.util.Collections sınıfında altı statik yöntemle bir koleksiyonun salt okunur bir sürümünü oluşturma yeteneği sağlar :

• değiştirilemezToplama (Koleksiyon c)
• değiştirilemezList (Liste listesi)
• değiştirilemez Harita (m)
• değiştirilemezSet (Set s)
• değiştirilemezSortedMap (SortedMap m)
• değiştirilemezSortedSet (SortedSet s)

Orijinal soruya yapılan yorumlarda birisinin belirttiği gibi, iade edilen koleksiyonlar değiştirilemez olarak kabul edilemez, çünkü koleksiyonlar değiştirilemese bile (koleksiyon eklenemez veya böyle bir koleksiyondan üye alınamaz), koleksiyon tarafından referans alınan gerçek nesneler Nesne türü izin veriyorsa değiştirilebilir.

Bununla birlikte, bu sorun, kodun tek bir nesneyi mi, yoksa değiştirilemez bir nesne koleksiyonu mu döndürdüğünden bağımsız olarak kalır. Tür nesnelerinin mutasyona uğramasına izin veriyorsa, o zaman tipin tasarımında bu karar verildi ve JCF'de yapılan bir değişikliğin bunu nasıl değiştirebileceğini görmüyorum. Değişmezlik önemliyse, bir koleksiyonun üyeleri değişmez türden olmalıdır.

Bu çok iyi bir soru. Java'da yazılan ve dünyanın her yerindeki milyonlarca bilgisayarda çalışan tüm kodların, her gün, günün her saatinde, toplam saat döngülerinin yaklaşık yarısının hiçbir şey yapmadan boşa harcanması gerektiği fikrinden zevk alıyorum. işlevler tarafından döndürülüyor. (Ve bu koleksiyonları yarattıktan sonra milisaniyeden fazla toplayanlar.)

Java programcılarının bir yüzdesi unmodifiableCollection(), Collectionssınıf metotları ailesinin varlığının farkındadır , ancak aralarında bile çoğu kişi bununla uğraşmıyor.

Ve onları suçlayamam: okuma yazma gibi davranan, ancak UnsupportedOperationExceptiononun 'yazma' yöntemlerinden herhangi birini çağırmakla hata yaparsanız bir atma yapacak bir arayüz olması çok kötü bir şeydir!

Şimdi, böyle bir arayüz Collectioneksik olur add(), remove()ve clear()yöntemler bir "ImmutableCollection" arayüzü olmaz; bir "Değiştirilemez Koleksiyon" arayüzü olurdu. Aslına bakılırsa, asla bir "Değiştirilebilir Toplama" arayüzü olamaz, çünkü değişmezlik bir uygulamanın özelliğidir, bir arayüzün özelliği değildir. Biliyorum, bu çok net değil; açıklamama izin ver.

Birinin size böyle bir salt okunur koleksiyon arabirimi verdiğini varsayalım; başka bir konuya geçmek güvenli midir? Bunun gerçekten değişmez bir koleksiyonu temsil ettiğinden emin olduğunu bilseydin cevabı "evet" olurdu; ne yazık ki, bir arayüz olduğu için, nasıl uygulandığını bilmiyorsunuz, bu nedenle cevabın hayır olması gerekiyor : bildiğiniz için, aslında değişebilen bir koleksiyonun değiştirilemez (sizin için) bir görüşü olabilir, (ne elde Collections.unmodifiableCollection()edeceğiniz gibi ), bu nedenle başka bir konu değiştirilirken ondan okumaya çalışmak yozlaşmış verilerin okunmasına neden olur.

Yani, temelde tanımladığınız şey "Değiştirilemez" değil, "Değiştirilemez" toplama arayüzleridir. "Değiştirilemez" in basitçe, böyle bir arayüze referansı olanın, altta yatan koleksiyonun değiştirilmesinin engellendiği anlamına geldiğini ve arayüzün zorunlu olarak değiştirilemez olmasından dolayı, arayüzün herhangi bir modifikasyon yönteminden yoksun olmasından dolayı önlenmesi gerektiğini anlamak önemlidir. Altta yatan koleksiyon çok iyi değişebilir olabilir; hakkında hiçbir bilginiz ve kontrolünüz yok.

Değişmez koleksiyonlara sahip olmak için ara yüz değil sınıf olmalılar !

Bu değişmez koleksiyon sınıflarının kesin olması gerekir, böylece böyle bir koleksiyona referans verildiğinde, kendiniz veya referansı olan ne olursa olsun, değişmeyen bir koleksiyon olarak davranacağından emin olduğunuzdan emin olabilirsiniz. onunla yap.

Bu nedenle, java'da (veya herhangi bir diğer zorunlu zorunlu dilde) eksiksiz bir koleksiyona sahip olmak için aşağıdakilere ihtiyacımız olacaktır:

1. Değiştirilemez koleksiyon arayüzleri kümesi .

2. Değiştirilemez olanları genişleten bir dizi değişken toplama arayüzü .

3. Değişken arayüzleri uygulayan ve ayrıca değiştirilemez arayüzleri genişleten bir dizi değişken toplama sınıfı .

4. Değiştirilemez arayüzleri uygulayan ancak değişmezliği garanti altına almak için çoğunlukla sınıf olarak dolaşan bir dizi değişmez koleksiyon sınıfı .

Yukarıdakilerin hepsini eğlenmek için uyguladım ve bunları projelerde kullanıyorum ve onlar bir cazibe gibi çalışıyorlar.

Java çalışma zamanının bir parçası olmamalarının nedeni, bunun bunun çok fazla / çok karmaşık / anlaşılmasının çok zor olduğu düşünülmesinden kaynaklanıyordu.

Şahsen, yukarıda açıkladığım şeyin bile yeterli olmadığını düşünüyorum; İhtiyaç duyulan bir şey daha, yapısal değişmezlik için bir dizi değişken arayüzler ve sınıflardır . ("Yapısal olarak tanımlanamaz" öneki çok uzun olduğu için basit olarak "Sert" olarak adlandırılabilir.)

Değiştirilemeyen koleksiyonlar birbirleriyle kıyaslandığında derinden özyinelemeli olabilir ve nesne eşitliği secureHash'la ise makul derecede etkin olamaz. Buna merkle ormanı denir. Bir toplama haritası için veya bunların içinde, sıralanmış bir harita için (kendi kendini dengeleyen ikili) AVL ağacı gibi olabilir.

Bu koleksiyonlardaki tüm java nesnelerinin benzersiz bir kimliği ya da karmaşasına bir bit çarpması olmadığı sürece, koleksiyonun kendisini benzersiz bir şekilde adlandıracak hiçbir şeyi yoktur.

Örnek: 4x1.6 ghz dizüstü bilgisayarımda, 500 K HashMap op ya da 3M op uzunluğunda bir hash ile karşılaştırıldığında, 1 hash döngüsüne uyan en küçük saniyenin saniyesinde 200K sha256s çalıştırabilirim. 200K / log (collectionSize) saniyede yeni koleksiyonlar, veri bütünlüğü ve adsız küresel ölçeklenebilirliğin önemli olduğu bazı şeyler için yeterince hızlı.

Verim. Koleksiyonlar doğası gereği çok büyük olabilir. Tek bir eleman yerleştirmek yerine 1000 elemanın 1001 elemanla yeni bir yapıya kopyalanması sadece korkunç bir durum.

Eşzamanlılık. Çalışan birkaç iş parçacığınız varsa, iş parçacığı başladığında 12 saat önce geçen sürümü değil koleksiyonun geçerli sürümünü almak isteyebilirsiniz.

Depolama. Çok dişli bir ortamda değişmez nesnelerle, yaşam döngüsünün farklı noktalarında "aynı" nesnenin düzinelerce kopyasını alabilirsiniz. Bir Takvim veya Tarih nesnesi için farketmez, ancak 10.000 widget koleksiyonu olduğunda sizi öldürür.