Lambda ifadelerinin kod satırlarını kaydetmekten başka bir kullanımı var mı?

Lambda ifadelerinin kod satırlarını kaydetmekten başka bir kullanımı var mı?

Lambdas tarafından sağlanan, çözülmesi kolay olmayan sorunları çözen özel özellikler var mı? Gördüğüm tipik kullanım, bunu yazmak yerine şudur:

Comparator<Developer> byName = new Comparator<Developer>() {
  @Override
  public int compare(Developer o1, Developer o2) {
    return o1.getName().compareTo(o2.getName());
  }
};

Kodu kısaltmak için bir lambda ifadesi kullanabiliriz:

Comparator<Developer> byName =
(Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName());

Lambda ifadeleri genel olarak Java ile çözebileceğiniz problemler kümesini değiştirmez, ancak belirli problemleri çözmeyi kesinlikle kolaylaştırır, sadece aynı nedenle artık assembly dilinde programlama yapmıyoruz. Gereksiz görevleri programcının çalışmasından kaldırmak hayatı kolaylaştırır ve başka türlü dokunmayacağınız şeyleri, yalnızca (manuel olarak) üretmeniz gereken kod miktarı için yapmanızı sağlar.

Ancak lambda ifadeleri yalnızca kod satırlarını kaydetmez. Lambda ifadeleri , daha önce geçici çözüm olarak anonim iç sınıfları kullanabileceğiniz işlevleri tanımlamanıza izin verir , bu nedenle bu durumlarda anonim iç sınıfları değiştirebilirsiniz, ancak genel olarak değil.

En önemlisi, lambda ifadeleri, dönüştürülecekleri işlevsel arabirimden bağımsız olarak tanımlanır, bu nedenle erişebilecekleri miras alınmış üyeler yoktur, ayrıca işlevsel arabirimi uygulayan türün örneğine erişemezler. Bir lambda ifadesi içinde thisve superçevresindeki bağlamında aynı anlama sahip, ayrıca bkz bu cevabı . Ayrıca, çevreleyen bağlamın yerel değişkenlerini gölgeleyen yeni yerel değişkenler oluşturamazsınız. Amaçlanan bir işlev tanımlama görevi için bu, birçok hata kaynağını ortadan kaldırır, ancak aynı zamanda diğer kullanım durumları için, işlevsel bir arabirim uygulansa bile bir lambda ifadesine dönüştürülemeyen anonim iç sınıflar olabileceği anlamına gelir.

Dahası, yapı new Type() { … }yeni bir farklı örnek oluşturmayı garanti eder ( newher zaman olduğu gibi). Anonim iç sınıf örnekleri, staticbağlam dışı olarak oluşturulmuşsa, her zaman dış örneklerine bir başvuru saklar . Buna karşılık, lambda ifadeleri, yalnızca bir başvuru yakalamak thiseriştikleri takdirde, ie gerektiğinde thisveya olmayan staticüyesi. Ayrıca, uygulamanın mevcut örnekleri yeniden kullanıp kullanmayacağına çalışma zamanında karar vermesine olanak tanıyan kasıtlı olarak belirtilmemiş bir kimliğin örneklerini üretirler (ayrıca bkz. " Bir lambda ifadesi, her yürütüldüğünde yığın üzerinde bir nesne oluşturur mu? ").

Bu farklılıklar örneğiniz için geçerlidir. Anonim iç sınıf yapınız her zaman yeni bir örnek üretir, ayrıca dış örneğe bir başvuru yakalayabilir, oysa sizin (Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName())tipik uygulamalarda bir tek ton olarak değerlendirilecek yakalamayan bir lambda ifadesidir. Ayrıca, .classsabit sürücünüzde bir dosya oluşturmaz .

Hem anlamsal hem de performansla ilgili farklılıklar göz önüne alındığında, lambda ifadeleri, elbette, yeni dil özelliklerini kullanan işlevsel programlama fikirlerini benimseyen yeni API'ler nedeniyle programcıların gelecekte belirli sorunları çözme şeklini değiştirebilir. Ayrıca bkz. Java 8 lambda ifadesi ve birinci sınıf değerler .

Programlama dilleri, makinelerin çalıştırması için değildir.

Programcıların düşünmesi içindir .

Diller, düşüncelerimizi bir makinenin yürütebileceği bir şeye dönüştürmek için bir derleyici ile yapılan görüşmedir. Diğer dillerden kendisine gelen (ya da insanlardan Java hakkında baş şikayetlerden biri terk onu için bu eskiden diğer diller) zorlar programcı belli bir zihinsel modeli (yani her şeyin bir sınıftır).

Bunun iyi ya da kötü olup olmadığına ağırlık vermeyeceğim: her şey değiş tokuş. Ancak Java 8 lambdas, programcıların daha önce Java'da yapamadığınız bir şey olan işlevler açısından düşünmesine izin verir .

Bu , Java'ya geldiklerinde sınıflar açısından düşünmeyi öğrenen bir yordamsal programcı ile aynı şey : onların yüceltilmiş yapılar olan sınıflardan yavaş yavaş hareket ettiğini ve bir grup statik yöntemle 'yardımcı' sınıflara sahip olduğunu görürsünüz ve rasyonel bir OO tasarımına (mea culpa) daha yakından benzer.

Bunları anonim iç sınıfları ifade etmenin daha kısa bir yolu olarak düşünürseniz, muhtemelen yukarıdaki prosedür programcısının muhtemelen sınıfların büyük bir gelişme olduğunu düşünmediği gibi onları çok etkileyici bulmayacaksınız.

Kod satırlarının kaydedilmesi, daha kısa ve daha net bir şekilde önemli miktarda mantık yazmanıza olanak sağlıyorsa, bu da başkalarının okuyup anlaması için daha az zaman alırsa, yeni bir özellik olarak görülebilir.

Lambda ifadeleri (ve / veya yöntem referansları) Streamolmasaydı ardışık düzenler çok daha az okunabilir olurdu.

Örneğin, Streamher lambda ifadesini anonim bir sınıf örneğiyle değiştirirseniz aşağıdaki ardışık düzeneğin nasıl görüneceğini düşünün .

List<String> names =
    people.stream()
          .filter(p -> p.getAge() > 21)
          .map(p -> p.getName())
          .sorted((n1,n2) -> n1.compareToIgnoreCase(n2))
          .collect(Collectors.toList());

Olurdu:

List<String> names =
    people.stream()
          .filter(new Predicate<Person>() {
              @Override
              public boolean test(Person p) {
                  return p.getAge() > 21;
              }
          })
          .map(new Function<Person,String>() {
              @Override
              public String apply(Person p) {
                  return p.getName();
              }
          })
          .sorted(new Comparator<String>() {
              @Override
              public int compare(String n1, String n2) {
                  return n1.compareToIgnoreCase(n2);
              }
          })
          .collect(Collectors.toList());

Bu, lambda ifadeleri içeren sürümden çok daha zordur ve hataya çok daha açıktır. Anlaması da daha zor.

Ve bu nispeten kısa bir boru hattı.

Bunu lambda ifadeleri ve yöntem referansları olmadan okunabilir hale getirmek için, burada kullanılan çeşitli işlevsel arabirim örneklerini tutan değişkenler tanımlamanız gerekirdi; bu, işlem hattının mantığını bölerek anlaşılmasını zorlaştırırdı.

Dahili yineleme

Java Koleksiyonlar yineleme olduğunda, çoğu geliştirici eğilimi olsun bir element ve sonra işlemek bunu. Bu, o öğeyi çıkarın ve sonra kullanın veya yeniden yerleştirin, vb. Java'nın 8'den önceki sürümleriyle, bir iç sınıfı uygulayabilir ve aşağıdaki gibi bir şey yapabilirsiniz:

numbers.forEach(new Consumer<Integer>() {
    public void accept(Integer value) {
        System.out.println(value);
    }
});

Şimdi Java 8 ile aşağıdakilerle daha iyi ve daha az ayrıntılı yapabilirsiniz:

numbers.forEach((Integer value) -> System.out.println(value));

ya da daha iyisi

numbers.forEach(System.out::println);

Argüman olarak davranışlar

Aşağıdaki durumu tahmin edin:

public int sumAllEven(List<Integer> numbers) {
    int total = 0;

    for (int number : numbers) {
        if (number % 2 == 0) {
            total += number;
        }
    } 
    return total;
}

Java 8 Predicate arayüzü ile şu şekilde daha iyisini yapabilirsiniz:

public int sumAll(List<Integer> numbers, Predicate<Integer> p) {
    int total = 0;

    for (int number : numbers) {
        if (p.test(number)) {
            total += number;
        }
    }
    return total;
}

Şöyle diyor:

sumAll(numbers, n -> n % 2 == 0);

Kaynak: DZone - Java'da Lambda İfadelerine Neden İhtiyacımız Var?

Aşağıdaki gibi iç sınıf yerine lambda kullanmanın birçok faydası vardır:

• Daha fazla dil sözdizimi semantiği eklemeden kodu daha kompakt ve anlamlı hale getirin. zaten sorunuzda bir örnek verdiniz.

• Lambdaları kullanarak, koleksiyonlardaki harita azaltma dönüşümleri gibi öğe akışları üzerinde işlevsel tarzda işlemlerle programlama yapmaktan mutlu olursunuz. bkz java.util.function & java.util.stream paketleri belgelerine.

• Derleyici tarafından lambdalar için oluşturulmuş fiziksel sınıflar dosyası yoktur. Böylece teslim edilen uygulamalarınızı küçültür. Bellek lambda'ya nasıl atanır?

• Lambda, kapsamı dışındaki değişkenlere erişmezse, bu, lambda örneğinin JVM tarafından yalnızca bir kez oluşturulduğu anlamına gelir. Daha fazla ayrıntı için @ Holger'ın soruya verdiği yanıtı görebilirsiniz. Yöntem referansını önbelleğe almak Java 8'de iyi bir fikir mi? .

• Lambdas, işlevsel arabirimin yanı sıra çoklu işaretleyici arabirimleri de uygulayabilir, ancak anonim iç sınıflar daha fazla arabirim uygulayamaz, örneğin:

  //                 v--- create the lambda locally.
  Consumer<Integer> action = (Consumer<Integer> & Serializable) it -> {/*TODO*/};

Lambdalar, anonim sınıflar için sadece sözdizimsel şekerdir.

Lambdalardan önce, aynı şeyi elde etmek için anonim sınıflar kullanılabilir. Her lambda ifadesi anonim bir sınıfa dönüştürülebilir.

IntelliJ IDEA kullanıyorsanız, dönüşümü sizin için yapabilir:

• İmleci lambda'ya getirin
• Alt / seçenek + enter tuşlarına basın

Soruna cevaben, aslına bakarsan lambda'lar olduğu yok sen önce java-8'e yapamayacağını şey yapmalarına izin, o, kendisi için daha fazla yazmak sağlayan özlü kodu. Bunun faydası, kodunuzun daha net ve daha esnek olmasıdır.

Henüz bahsetmediğim bir şey, lambda'nın kullanıldığı yerde işlevselliği tanımlamanıza izin vermesidir .

Dolayısıyla, basit bir seçim işleviniz varsa, onu bir grup standart şablonla ayrı bir yere koymanıza gerek yoktur, sadece kısa ve yerel olarak alakalı bir lambda yazarsınız.

Evet birçok avantajı var.

• Tüm sınıfı tanımlamaya gerek yok, işlevin uygulanmasını referans olarak kendimize iletebiliriz.
  • Sınıfın dahili olarak oluşturulması .class dosyası oluştururken, lambda kullanırsanız, sınıf oluşturma derleyici tarafından engellenir çünkü lambda'da sınıf yerine işlev uygulamasını iletiyorsunuz.
• Kod yeniden kullanılabilirliği öncekinden daha yüksek
• Ve dediğiniz gibi kod normal uygulamadan daha kısadır.