Is using Lambda expressions whenever possible in java good practice?

Question

I have recently mastered the Lambda expression that was introduced in java 8. I find that whenever I am using a functional interface, I tend to always use a Lambda expression instead of creating a class that implements the functional interface.

Is this considered good practice? Or are their situations where using a Lambda for a functional interface is not appropriate?

Answer 1

There are a number of criteria that should make you consider not using a lambda:

• Size The larger a lambda gets, the more difficult it makes it to follow the logic surrounding it.
• Repetition It's better to create a named function for repeated logic, although it's okay to repeat very simple lambdas that are spread apart.
• Naming If you can think of a great semantic name, you should use that instead, as it adds a lot of clarity to your code. I'm not talking names like priceIsOver100. x -> x.price > 100 is just as clear as that name. I mean names like isEligibleVoter that replace a long list of conditions.
• Nesting Nested lambdas are really, really hard to read.

Don't go overboard. Remember, software is easily changed. When in doubt, write it both ways and see which is easier to read.

Answer 2

I support Karl Bielefeldt's answer, but want to provide a brief addition.

• Debugging Some IDE's struggle with scope inside of a lambda, and struggle to display member variables inside the context of a lambda. While hopefully this situation will change down the line, it can be annoying to maintain someone else's code when it is littered with lambdas.

Answer 3

It depends. Whenever you find yourself using the same lambda in different places you should consider implementing a class that implements the interface. But if you would've used an anonymous inner class otherwise I think a lambda is far better.

Answer 4

Access to local variables of the enclosing scope

The accepted Answer by Karl Bielefeldt is correct. I can add one more distinction:

• Scope

The lambda code nested inside a method inside a class can access any effectively-final variables found within that method & class.

Creating a class that implements the functional interface does not give you such direct access to the state of the calling code.

To quote the Java Tutorial (emphasis mine):

Like local and anonymous classes, lambda expressions can capture variables; they have the same access to local variables of the enclosing scope. However, unlike local and anonymous classes, lambda expressions do not have any shadowing issues (see Shadowing for more information). Lambda expressions are lexically scoped. This means that they do not inherit any names from a supertype or introduce a new level of scoping. Declarations in a lambda expression are interpreted just as they are in the enclosing environment.

So while there are benefits to pulling out long code and naming it, you must weigh that against the simplicity of direct access to the state of the enclosing method & class.

See:

• Accessing Local Variables of the Enclosing Scope (Java Tutorials by Oracle)
• What is the benefit being able to use effectively final variables in Java 8 lambda expressions
• Difference between final and effectively final

Answer 5

This might be nit-picking, but to all the other excellent points made in other answers, I would add:

Prefer Method References when possible. Compare:

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

versus

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

Using a method reference saves you the need to name the lambda's argument(s), which is usually redundant and/or leads to lazy names like e or x.

Answer 6

Building on Matt McHenry's answer, there can be a relationship between lambda and method references where the lambda can be re-written as a series of method references. For example:

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

vs

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