Dominei recentemente a expressão Lambda que foi introduzida no java 8. Acho que sempre que estou usando uma interface funcional, costumo sempre usar uma expressão Lambda em vez de criar uma classe que implementa a interface funcional.

Isso é considerado uma boa prática? Ou são as situações em que o uso de um Lambda para uma interface funcional não é apropriado?

Há vários critérios que devem fazer você considerar não usar um lambda:

• Tamanho Quanto maior o lambda, maior a dificuldade de seguir a lógica que o cerca.
• Repetição É melhor criar uma função nomeada para lógica repetida, embora seja bom repetir lambdas muito simples que são separadas.
• Nomeação Se você puder pensar em um ótimo nome semântico, use-o, pois ele adiciona muita clareza ao seu código. Eu não estou falando nomes como priceIsOver100. x -> x.price > 100é tão claro quanto esse nome. Quero dizer que nomes assim isEligibleVotersubstituem uma longa lista de condições.
• Aninhamento Lambdas aninhadas são muito, muito difíceis de ler.

Não exagere. Lembre-se, o software é facilmente alterado. Em caso de dúvida, escreva nos dois sentidos e veja qual é mais fácil de ler.

Depende. Sempre que você se encontrar usando o mesmo lambda em lugares diferentes, considere implementar uma classe que implemente a interface. Mas se você usasse uma classe interna anônima, caso contrário, acho que um lambda é muito melhor.

Apoio a resposta de Karl Bielefeldt, mas quero fornecer uma breve adição.

• Depurando Alguns IDE lutam com o escopo dentro de um lambda e lutam para exibir variáveis ​​de membros dentro do contexto de um lambda. Embora, esperançosamente, essa situação mude na linha, pode ser irritante manter o código de outra pessoa quando estiver cheio de lambdas.

Acesso a variáveis ​​locais do escopo anexo

A resposta aceita por Karl Bielefeldt está correta. Eu posso adicionar mais uma distinção:

• Escopo

O código lambda aninhado dentro de um método dentro de uma classe pode acessar quaisquer variáveis efetivamente finais encontradas dentro desse método e classe.

Criar uma classe que implemente a interface funcional não fornece acesso direto ao estado do código de chamada.

Para citar o Tutorial Java (ênfase minha):

Como as classes locais e anônimas, as expressões lambda podem capturar variáveis; eles têm o mesmo acesso a variáveis ​​locais do escopo anexo . No entanto, diferentemente das classes local e anônima, as expressões lambda não apresentam problemas de sombreamento (consulte Shadowing para obter mais informações). Expressões lambda têm escopo lexicamente. Isso significa que eles não herdam nenhum nome de um supertipo ou introduzem um novo nível de escopo. As declarações em uma expressão lambda são interpretadas da mesma forma que no ambiente anexo.

Portanto, embora haja vantagens em extrair um código longo e nomeá-lo, você deve ponderá-lo contra a simplicidade do acesso direto ao estado do método e da classe anexos.

Vejo:

• Acessando variáveis ​​locais do escopo de fechamento ( Java Tutorials by Oracle)
• Qual é o benefício de poder usar efetivamente variáveis ​​finais nas expressões lambda do Java 8
• Diferença entre final e efetivamente final

Isso pode ser muito difícil, mas para todos os outros pontos excelentes apresentados em outras respostas, eu acrescentaria:

Prefira as referências do método quando possível. Comparar:

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

versus

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

Usar uma referência de método poupa a necessidade de nomear os argumentos do lambda, que geralmente são redundantes e / ou levam a nomes preguiçosos como eou x.

Com base na resposta de Matt McHenry, pode haver um relacionamento entre as referências lambda e o método em que o lambda pode ser reescrito como uma série de referências a métodos. Por exemplo:

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

vs

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