Tiny Java test exploring polymorphism and maintainability when map()ing a method ref vs. a lambda
Java
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
src/test/java/com/thoughtpropulsion/lambdavsmethodref
.gitignore
README.md
pom.xml

README.md

Companion blog post on Memerocket: Use Java Lambdas Instead of Method Refs Sometimes

When map()ing via Java streams or Optional, it's often convenient to use method references:

interface Speaker {
    String speak();
}

class AdmiralStockdale implements Speaker {
    public String speak() {return "gridlock!";}
}

final Optional<Speaker> speaker = Optional.of(new AdmiralStockdale());

System.out.println(speaker.map(Speaker::speak).get());

=> "gridlock!"

But because a method reference always includes a class (or interface) name this sometimes seems needlessly verbose. (Speaker::speak). It's not only verbose—it's worse than that. It mentions the class (interface) name. This often forces the developer to go look up that name. Later, that name must be maintained.

An alternative is to use lambda:

System.out.println(speaker.map(s->s.speak()).get());

=> "gridlock!"

At the point where we send the speak() message, we don't assume anything about the type of a—only that it can speak().

The compiler takes care of figuring out if s (speaker) can speak(). Later, if the class names, or class/interface hierarchy change, our mapping code is stable. As with a method reference, our type checker ensures compatibility.

Don't repeat yourself!