1. Prefer standard functional interfaces
We should apply the standard functional interfaces from package java.util.function whenever applicable. There are six basic functional interfaces that we can remember for convenience. The other standard functional interfaces can be derived the basic ones easily.
* The above table is taken from book Effective Java 3rd edition
Here an example applying Predicate and Consumer:
public static void main(String[] args) {
List personList = Arrays.asList(
new Person("Sajib", "Amin", 34),
new Person("Salman", "Rishad", 34),
new Person("Shafiul", "Hasan", 34),
new Person("Anitam", "Das", 26),
new Person("Khaled", "Sazzad", 26));
Collections.sort(personList, (p1, p2) ->
p1.getLastName().compareTo(p2.getLastName()));
printConditionally(personList,
p -> p.getFirstName().startsWith("S"),
p -> System.out.println(p.getFirstName()));
}
private static void printConditionally(List personList,
Predicate predicate, Consumer consumer) {
for (Person p : personList) {
if (predicate.test(p)) {
consumer.accept(p);
}
}
}
2. Use the @FunctionalInterface annotation
We should annotate our custom functional interfaces with @FunctionalInterface. If we don’t annotate, other developers can accidentally add more abstract methods and break the conditions of using it as a functional interface.
3. Don’t overuse default methods in functional interfaces
We should not make excessive use of default methods in a functional interface. Excessive use can introduce situations where default method with same name will exist in two separate interfaces and another interface is trying to extend them both.
Adding too many default methods to the interface is not a very good architectural decision. It is should be viewed as a compromise, only to be used when required, for upgrading existing interfaces without breaking backward compatibility.
4. Prefer lambdas to anonymous classes
A functional interface can be implemented using an anonymous inner class. But, that should be avoided as much as possible. Lambda expression should be used in such cases. For example, here is an anonymous inner class implementation of Comparator:
Collections.sort(wordList, new Comparator() {
@Override
public int compare(String s1, String s2) {
return s1.compareTo(s2);
}
});
It should be replaced with lambda expression like
Collections.sort(wordList, (s1, s2) -> s1.compareTo(s2));
5. Avoid overloading methods with functional interfaces as parameters
When functional interfaces are used as parameters in method, we should avoid overloaded use of them. Method with different name can be used to avoid collision. A good example is available here.
6. Don’t treat lambda expressions as inner classes
When we instantiate an inner class, it creates a new scope. We can overwrite local variables from the enclosing scope by instantiating new local variables with the same names. We can also use the keyword this inside our inner class as a reference to its instance.
Lambda expression does not create its own scope, it relies on the enclosing scope. We can’t overwrite variables from the enclosing scope inside the lambda’s body. In this case, the keyword this is a reference to an enclosing instance. A good example is available here.
7. Use effectively final variables
Lambda expressions can access final variables only. Accessing a non-final variable inside lambda expressions will cause the compile-time error. However, we do not need to mark the variable with final keyword. As long as the variable is assigned value only once, compiler will treat it as effectively final.
8. Keep lambda expressions short and self-explanatory
a) Avoid blocks of code in lambda’s body
One liner is ideal for lambda expression. Large block of code can be encapsulated inside a method in some cases.
b) Avoid specifying parameter types
Parameter types are usually omitted. (a, b) -> should be used instead of (String a, String b) ->
c) Avoid parentheses around a single parameter
For single parameter, use of parentheses is unnecessary. a -> should be used instead if (a) ->
d) Avoid return statement and braces
Braces and return statements are optional in one liner lambda expression. So, a -> a.toLowerCase() should be used instead of a -> {return a.toLowerCase()}
e) Use method references
Method reference is already discussed in previous post. It is recommended to replace lambda expression with method reference whenever it is applicable.
References:
