Java akışları gerçekten sadece hata ayıklama için bakmak mı?

Java akışları hakkında okuyorum ve devam ederken yeni şeyler keşfediyorum. Bulduğum yeni şeylerden biri peek()işlevdi. Gözden geçirdiğim hemen hemen her şey, akışlarınızın hata ayıklaması için kullanılması gerektiğini söylüyor.

Her bir Hesabın bir kullanıcı adı, şifre alanı ve bir login () ve loginIn () yöntemine sahip olduğu bir Akışım olsaydı ne olurdu.

Bende var

Consumer<Account> login = account -> account.login();

ve

Predicate<Account> loggedIn = account -> account.loggedIn();

Bu neden bu kadar kötü?

List<Account> accounts; //assume it's been setup
List<Account> loggedInAccount = 
accounts.stream()
    .peek(login)
    .filter(loggedIn)
    .collect(Collectors.toList());

Şimdi söyleyebildiğim kadarıyla bunun tam olarak ne yapması gerektiğini yapıyor. O;

• Hesapların bir listesini alır
• Her hesaba giriş yapmayı dener
• Giriş yapmayan tüm hesapları filtreler
• Giriş yapılmış hesapları yeni bir listede toplar

Böyle bir şey yapmanın dezavantajı nedir? Devam etmememin bir nedeni var mı? Son olarak, bu çözüm değilse ne olacak?

Bunun orijinal sürümü .filter () yöntemini aşağıdaki gibi kullanmıştır;

.filter(account -> {
        account.login();
        return account.loggedIn();
    })

Bu konudaki temel paket:

Anında hedefinize ulaşsa bile API'yı istenmeyen bir şekilde kullanmayın. Bu yaklaşım gelecekte kırılabilir ve gelecekteki koruyucular için de belirsizdir.

Farklı operasyonlar oldukları için bunu birden fazla operasyona ayırmanın bir zararı yoktur. API'nın belirsiz ve istenmeyen bir şekilde kullanılmasında zarar vardır ; bu, Java'nın gelecekteki sürümlerinde bu özel davranış değiştirilirse sonuçları olabilir.

forEachBu işlemi kullanmak , bakıcıya her öğesinde amaçlanan bir yan etki accountsolduğunu ve onu değiştirebilecek bir işlem gerçekleştirdiğinizi açıklığa kavuşturacaktır .

Ayrıca peek, terminal işlemi çalışana kadar tüm koleksiyonda çalışmayan, ancak forEachgerçekten bir terminal işlemi olan bir ara işlem olması bakımından daha gelenekseldir . Bu yolla, kodunuzun davranışı ve akışı hakkında , bu bağlamda peekolduğu gibi davranıp davranmayacağına dair soru sormanın aksine güçlü argümanlar yapabilirsiniz forEach.

accounts.forEach(a -> a.login());
List<Account> loggedInAccounts = accounts.stream()
                                         .filter(Account::loggedIn)
                                         .collect(Collectors.toList());

Anlamanız gereken önemli şey, akışların terminal işlemi tarafından yönlendirilmesidir . Terminal işlemi, tüm elemanların işlenip işlenmeyeceğini veya herhangi bir işlemin yapılacağını belirler. Yani collect, oysa her bir öğeyi işleyen bir işlemdir findAnybunun, eşleşen eleman karşılaştı kez işleme öğeleri durdurabilir.

Ve count()öğeleri işlemeden akışın boyutunu belirleyebildiği zaman hiçbir öğeyi işlemeyebilir. Bu, Java 8'de yapılmayan ancak Java 9'da olacak bir optimizasyon olduğundan, Java 9'a geçtiğinizde ve count()tüm öğeleri işlemek için koda sahip olduğunuzda sürprizler olabilir . Bu aynı zamanda diğer uygulamaya bağlı ayrıntılara da bağlıdır, örneğin Java 9'da bile, referans uygulaması, limitbu tür bir öngörüyü engelleyen temel bir sınırlama bulunmamakla birlikte, sonsuz bir akış kaynağının boyutunu bir araya getiremez .

Yana peeksağlayan “her bir elemanın üzerinde işlem gerçekleştirmek elemanları ortaya çıkan akımdan tüketildiği kadar ”, bu elementlerin işlem zorunlu değildir ama uç çalışma gereksinimlerine bağlı olarak hareket gerçekleştirir. Bu, belirli bir işleme ihtiyacınız varsa, örneğin tüm öğelere bir eylem uygulamak istiyorsanız, bunu büyük bir dikkatle kullanmanız gerektiği anlamına gelir. Terminal işleminin tüm öğeleri işlemesi garanti edilirse çalışır, ancak o zaman bile, bir sonraki geliştiricinin terminal işlemini değiştirmediğinden emin olmalısınız (veya bu ince yönü unutursunuz).

Ayrıca, akışlar, paralel akışlar için bile belirli bir işlem birleşimi için karşılaşma düzenini korumayı garanti ederken, bu garantiler geçerli değildir peek. Bir listeye toplanırken, ortaya çıkan liste sıralı paralel akışlar için doğru sıraya sahip olacaktır, ancak peekeylem keyfi bir sırada ve eşzamanlı olarak çağrılabilir.

Dolayısıyla, yapabileceğiniz en yararlı şey peek, API belgelerinin tam olarak söylediği bir akış öğesinin işlenip işlenmediğini bulmaktır:

Bu yöntem esas olarak, bir boru hattındaki belirli bir noktayı geçtikçe öğeleri görmek istediğiniz hata ayıklamayı desteklemek için bulunur.

Belki de bir kural, "hata ayıklama" senaryosunun dışında bir göz kullanırsanız, bunu yalnızca sonlandırma ve ara filtreleme koşullarının ne olduğundan eminseniz yapmanız gerekir. Örneğin:

return list.stream().map(foo->foo.getBar())
                    .peek(bar->bar.publish("HELLO"))
                    .collect(Collectors.toList());

tek bir operasyonda tüm Foos'u Barlara dönüştürmek ve hepsine merhaba demek için geçerli bir durum gibi görünüyor.

Gibi bir şeyden daha verimli ve zarif görünüyor:

List<Bar> bars = list.stream().map(foo->foo.getBar()).collect(Collectors.toList());
bars.forEach(bar->bar.publish("HELLO"));
return bars;

ve bir koleksiyonu iki kez yinelemezsiniz.

Her şeyi bir terminal yöntemine geçirilen basit veya oluşturulmuş bir işleve doldurmak yerine, akış nesnelerini değiştirebilen veya küresel durumu (bunlara dayalı olarak) değiştirebilen kodu ademi merkezileştirmepeek yeteneği sağladığını söyleyebilirim .

Şimdi soru şu olabilir: Akış nesnelerini mutasyona uğratmalı veya işlevsel durumu java programlamadaki işlevlerden küresel durumu değiştirmeli miyiz?

2 Yukarıdaki sorulardan herhangi birine cevabınız evet (veya: Bazı durumlarda evet de) daha sonra peek()ise kesinlikle sadece hata ayıklama amacıyla , aynı nedenle forEach()hata ayıklama amacıyla değil sadece .

Benim için forEach()ve arasında peek()seçim yaparken, aşağıdakileri seçiyor: Akış nesnelerini değiştiren kod parçalarının birleştirilebilir bir öğeye eklenmesini mi yoksa doğrudan akışa eklemelerini ister miyim?

peek()Java9 yöntemleri ile daha iyi eşleşeceğini düşünüyorum . örneğin takeWhile(), zaten mutasyon geçirmiş bir nesneye dayalı olarak yinelemenin ne zaman durdurulacağına karar vermesi gerekebilir, bu nedenle onu eşleştirmek forEach()aynı etkiye sahip olmaz.

PS Hiçbir map()yere başvurmadım çünkü yeni nesneler üretmek yerine nesneleri (veya küresel durumu) değiştirmek istersek, tam olarak aynı şekilde çalışır peek().

Yukarıdaki cevapların çoğuna katılmama rağmen, peek kullanımının aslında en temiz yol gibi göründüğü bir durum var.

Kullanım durumunuza benzer şekilde, yalnızca etkin hesaplara filtre uygulamak ve ardından bu hesaplarda bir giriş yapmak istediğinizi varsayalım.

accounts.stream()
    .filter(Account::isActive)
    .peek(login)
    .collect(Collectors.toList());

Peek, koleksiyonu iki kez tekrarlamak zorunda kalmadan gereksiz çağrıdan kaçınmak için yararlıdır:

accounts.stream()
    .filter(Account::isActive)
    .map(account -> {
        account.login();
        return account;
    })
    .collect(Collectors.toList());

İşlevsel çözüm, hesap nesnesini değiştirilemez hale getirmektir. Yani account.login () yeni bir hesap nesnesi döndürmelidir. Bu, harita işleminin peek yerine oturum açma için kullanılabileceği anlamına gelir.