Недавно я освоил лямбда-выражение, которое было введено в java 8. Я обнаружил, что всякий раз, когда я использую функциональный интерфейс, я склонен всегда использовать лямбда-выражение вместо создания класса, реализующего функциональный интерфейс.

Это считается хорошей практикой? Или их ситуации, когда использование лямбды для функционального интерфейса не подходит?

Существует ряд критериев, которые следует учитывать при использовании лямбды:

• Размер Чем больше становится лямбда, тем сложнее ей следовать логике, окружающей ее.
• Повторение Лучше создать именованную функцию для повторяющейся логики, хотя можно повторять очень простые лямбды, которые разбросаны.
• Присвоение имен Если вы можете придумать хорошее семантическое имя, вы должны использовать его вместо этого, так как оно добавляет большую ясность вашему коду. Я не говорю такие имена, как priceIsOver100. x -> x.price > 100так же ясно, как это имя. Я имею в виду такие имена, isEligibleVoterкоторые заменяют длинный список условий.
• Вложенность Вложенные лямбды действительно очень трудно читать.

Не уходи за борт. Помните, программное обеспечение легко меняется. Если сомневаетесь, напишите обоими способами и посмотрите, что легче читать.

По-разному. Всякий раз, когда вы обнаруживаете, что используете одну и ту же лямбду в разных местах, вам следует подумать о реализации класса, реализующего интерфейс. Но если бы вы использовали анонимный внутренний класс, иначе я думаю, что лямбда гораздо лучше.

Я поддерживаю ответ Карла Билефельдта, но хочу дать краткое дополнение.

• Отладка Некоторая борьба IDE с областью действия внутри лямбды и борьба за отображение переменных-членов в контексте лямбды. Хотя мы надеемся, что эта ситуация изменится в дальнейшем, это может быть раздражающим, чтобы поддерживать чужой код, когда он завален лямбдами.

Доступ к локальным переменным вмещающей области

Принятый ответ Карла Билефельдта правильный. Я могу добавить еще одно различие:

• Объем

Лямбда-код, вложенный в метод внутри класса, может получить доступ к любым эффективно- конечным переменным, найденным в этом методе и классе.

Создание класса, реализующего функциональный интерфейс, не дает вам такого прямого доступа к состоянию вызывающего кода.

Чтобы процитировать Java Tutorial (курсив мой):

Как и локальные и анонимные классы, лямбда-выражения могут захватывать переменные; они имеют одинаковый доступ к локальным переменным окружения . Однако, в отличие от локальных и анонимных классов, у лямбда-выражений нет проблем с теневым копированием (для получения дополнительной информации см. Теневое копирование). Лямбда-выражения лексически ограничены. Это означает, что они не наследуют никаких имен от супертипа или вводят новый уровень видимости. Объявления в лямбда-выражении интерпретируются так же, как и во внешней среде.

Таким образом, несмотря на преимущества извлечения длинного кода и присвоения ему имен, вы должны сравнить это с простотой прямого доступа к состоянию включающего метода и класса.

Видеть:

• Доступ к локальным переменным в прилагаемой области ( Учебные руководства по Java от Oracle)
• В чем преимущество возможности эффективно использовать конечные переменные в лямбда-выражениях Java 8
• Разница между окончательным и фактически окончательным

Это может быть придиркой, но ко всем другим замечательным замечаниям, высказанным в других ответах, я бы добавил:

Предпочитайте ссылки на метод, когда это возможно. Для сравнения:

employees.stream()
         .map(Employee::getName)
         .forEach(System.out::println);

против

employees.stream()
         .map(employee -> employee.getName())
         .forEach(employeeName -> System.out.println(employeeName));

Использование ссылки на метод избавляет вас от необходимости называть лямбда-аргумент (ы), который обычно избыточен и / или приводит к ленивым именам, таким как eили x.

Основываясь на ответе Мэтта МакГенри, между лямбдой и ссылками на методы может существовать связь, где лямбда может быть переписана в виде серии ссылок на методы. Например:

employees.stream()
         .forEach(employeeName -> System.out.println(employee.getName()));

против

employees.stream()
         .map(Employee::getName)
         .forEach(System.out::println);