Чи використовуються лямбда-вирази, окрім збереження рядків коду?

Чи використовуються лямбда-вирази, окрім збереження рядків коду?

Чи є якісь особливості, що надаються лямбдами, які вирішували проблеми, які нелегко було вирішити? Типове використання, яке я бачив, це те, що замість цього писати:

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

Ми можемо використовувати лямбда-вираз для скорочення коду:

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

Ламбда-вирази не змінюють набір проблем, які можна вирішити за допомогою Java взагалі, але, безумовно, полегшують вирішення певних проблем, просто з тієї ж причини, що ми більше не програмуємо на мові складання. Видалення зайвих завдань з роботи програміста полегшує життя і дозволяє робити речі, які ви навіть не торкалися б інакше, лише за кількість коду, який ви повинні створити (вручну).

Але лямбда-вирази - це не просто збереження рядків коду. Ламбда-вирази дозволяють визначати функції , для чого ви могли раніше використовувати анонімні внутрішні класи як вирішення, тому ви можете замінити анонімні внутрішні класи в цих випадках, але не в цілому.

Найбільш помітно, що лямбда-вирази визначаються незалежно від функціонального інтерфейсу, до якого вони будуть перетворені, тому немає спадкових членів, до яких вони могли б отримати доступ, крім того, вони не можуть отримати доступ до екземпляра типу, що реалізує функціональний інтерфейс. У лямбдаському виразі thisта superмають те саме значення, що й у навколишньому контексті, дивіться також цю відповідь . Крім того, ви не можете створити нові локальні змінні, що відтіняють локальні змінні оточуючого контексту. Для заданого завдання визначення функції це видаляє багато джерел помилок, але це також означає, що для інших випадків використання можуть існувати анонімні внутрішні класи, які не можуть бути перетворені на лямбда-вираз, навіть якщо реалізувати функціональний інтерфейс.

Крім того, конструкція new Type() { … }гарантує створення нового чіткого екземпляра (як newзавжди). Анонімні екземпляри внутрішнього класу завжди зберігають посилання на їх зовнішній екземпляр, якщо вони створені в неконтексті static. Навпаки, лямбда-вирази містять посилання лише на thisнеобхідність, тобто якщо вони мають доступ thisабо не є staticчленом. І вони створюють екземпляри навмисно невизначеної ідентичності, що дозволяє впровадженню вирішити під час виконання, чи використовувати повторно існуючі екземпляри (див. Також " Чи створює лямбда-вираз об'єкт на купі кожного разу, коли він виконується? ").

Ці відмінності стосуються вашого прикладу. Ваша анонімна конструкція внутрішнього класу завжди створюватиме новий екземпляр, також вона може захоплювати посилання на зовнішній екземпляр, тоді як ваш (Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName())- вираз лямбда, що не захоплює, який буде оцінюватися на синглтон в типових реалізаціях. Крім того, він не створює .classфайл на вашому жорсткому диску.

Зважаючи на відмінності як щодо семантичного, так і продуктивного характеру, лямбда-вирази можуть змінити спосіб програмістів вирішувати певні проблеми в майбутньому, звичайно, також завдяки новим API, що використовують ідеї функціонального програмування з використанням нових мовних особливостей. Дивіться також вираз лямбда-вираз і значення першого класу Java 8 .

Мови програмування не призначені для виконання машин.

Вони для того, щоб програмісти задумалися .

Мови - це розмова з компілятором, щоб перетворити наші думки у те, що може виконати машина. Однією з головних скарг на Яву від людей, які приходять до неї з інших мов (або залишають її для інших мов), було те, що вона змушує програміста певну ментальну модель (тобто все - це клас).

Я не збираюся зважуватись на те, добре чи погано: все є компромісом. Але лямбди Java 8 дозволяють програмістам мислити з точки зору функцій , що раніше ви не могли зробити в Java.

Це те саме, що процедурний програміст, який навчається думати через класи, коли вони приходять на Яву: ви бачите, як вони поступово переходять від класів, які прославляють структури, і мають "помічницькі" класи з купою статичних методів і переходять до чогось, що більше нагадує раціональну конструкцію ОО (mea culpa).

Якщо ви просто думаєте про них як про коротший спосіб виразити анонімні внутрішні класи, то, ймовірно, ви не будете вважати їх дуже вражаючими так само, як і процедурний програміст, напевно, не вважав, що заняття не мають великого покращення.

Збереження рядків коду можна розглядати як нову функцію, якщо це дає змогу коротше і чіткіше писати суттєвий фрагмент логіки, що потребує меншого часу для читання та розуміння інших.

Без лямбда-виразів (та / або посилань на методи) Streamтрубопроводи були б набагато менш читабельні.

Подумайте, наприклад, як Streamвиглядав би наступний конвеєр, якби ви замінили кожен лямбда-вираз на анонімний екземпляр класу.

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

Це було б:

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());

Це набагато складніше написати, ніж версія з лямбда-виразами, і вона набагато більше схильна до помилок. Це також важче зрозуміти.

І це порівняно короткий трубопровід.

Щоб зробити це читабельно без лямбда-виразів та посилань на методи, вам довелося б визначити змінні, які містять тут використовувані різні екземпляри функціонального інтерфейсу, які б розділили логіку конвеєра, ускладнюючи його розуміння.

Внутрішня ітерація

Під час ітерації Java Collection, більшість розробників прагне отримати елемент і потім обробити його. Це - вийміть цей елемент, а потім використовуйте його або повторно вставляйте його тощо. За допомогою попередніх 8 версій Java ви можете реалізувати внутрішній клас і зробити щось на кшталт:

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

Тепер з Java 8 ви можете робити кращі та менші докладно:

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

або краще

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

Поведінки як аргументи

Відгадайте наступний випадок:

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

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

З інтерфейсом предикату Java 8 ви можете краще зробити так:

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

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

Називаючи це так:

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

Джерело: DZone - навіщо нам потрібні лямбда-вирази на Java

Існує багато переваг використання лямбда замість внутрішнього класу, як описано нижче:

• Зробіть код більш компактним та виразним, не вводячи більше семантики синтаксису мови. ви вже наводили приклад у своєму запитанні.

• Використовуючи лямбда, ви раді програмуванню за допомогою операцій у функціональному стилі на потоках елементів, таких як перетворення на зменшення карти на колекції. див . документацію щодо пакетів java.util.function & java.util.stream .

• Файл фізичних класів, створений компілятором для лямбда, не створюється. Таким чином, це робить ваші доставлені програми меншими. Як пам'ять призначає лямбда?

• Компілятор оптимізує створення лямбда, якщо лямбда не отримає доступ до змінних за межами своєї області, що означає, що екземпляр лямбда створюється лише один раз JVM. Детальніше ви можете побачити відповідь @ Holger на питання Чи хороша ідея кешування посилань на Java 8? .

• Lambdas може реалізувати багатомаркерові інтерфейси, крім функціонального інтерфейсу, але анонімні внутрішні класи не можуть реалізувати більше інтерфейсів, наприклад:

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

Лямбди - це просто синтаксичний цукор для анонімних занять.

Перед лямбдами, анонімні заняття можна використовувати для досягнення того ж самого. Кожен вираз лямбда може бути перетворений в анонімний клас.

Якщо ви використовуєте IntelliJ IDEA, він може зробити перетворення для вас:

• Покладіть курсор в лямбду
• Натисніть alt / option + enter

Щоб відповісти на ваше запитання, справа в тому, що лямбдаси не дозволяють вам робити нічого, чого ви не могли зробити до java-8, скоріше, це дозволяє вам написати більш стислий код. Переваги цього в тому, що ваш код буде чіткішим і гнучкішим.

Одне, що я ще не бачу згадати, - це те, що лямбда дозволяє визначати функціональність, де вона використовується .

Тож якщо у вас є якась проста функція вибору, вам не потрібно ставити її в окремому місці з купою котла, просто напишіть лямбда, який є стислим і місцевим.

Так, багато переваг є.

• Не потрібно визначати цілий клас, ми можемо передати реалізацію функції як самостійна.
  • Внутрішнє створення класу створить .class файл, тоді як якщо ви використовуєте лямбда, то створення класу уникає компілятор, оскільки в лямбда ви передаєте реалізацію функції замість класу.
• Повторне використання коду вище, ніж раніше
• І як ви сказали, код коротший, ніж звичайна реалізація.