Let’s Use Optional to Fix Method Contracts
- November 10, 2021
- 2060 Unique Views
- 2 min red
A method is a contract: when we define one, we put thought into it. We specify parameters with their type and also a return type. When we invoke a method, we expect it to behave according to the contract. If it doesn’t, it’s a violation of the contract.
We have been dealing with such violations all the time. We invoke a method with its proper arguments and we get a return. However, sometimes we end up getting a null, which is, in fact, a clear violation. We shouldn’t accept such a violation. If a method cannot return the value of the specified type, it should mention that in the method signature, the method may or may not be returning the value you are expecting. If we know it from the method signature, we then write our code accordingly.
Now the question is, how do we define such a contract in a method signature? Well, that’s where Optional comes into play. Set your return type as Optional. Optional is a mystery box, a wrapping paper: it may or may not contain the value. When we specify that in a method signature, we assume that the box might be empty. Let’s see an example:
public static Optional<Book> findBookByName(String name) {
return books.stream()
.filter(book -> book.title().equalsIgnoreCase(name))
.findAny();
}
The method above specified Optional as a return type. It may return the book that I’m looking for or may not. I’m aware of this, and I can deal with it when I invoke it. For example:
var bookOpt = findBookByName("Java Programming");
if (bookOpt.isPresent()) {
var book = bookOpt.get();
var releasedYear = book.releasedYear();
System.out.println("Java Programming was published in " + releasedYear);
} else {
System.out.println("Book was not found");
}
Or we can do the same thing with the functional construct, e.g:
findBookByName("Java Programming")
.map(Book::releasedYear)
.ifPresentOrElse((releasedYear)
-> System.out.println("Java Programming was published in " + releasedYear),
() -> System.out.println("Book was not found"));
The bottom line is, we should fix our method contract and use optional rather than returning null.
Don’t Forget to Share This Post!
A N M Bazlur Rahman is a Software Engineer with over a decade of specialized experience in Java and related technologies. His expertise has been formally recognized through the prestigious title of Java Champion. Beyond his professional commitments, Mr. Rahman is deeply involved in community outreach and education. He is the founder and current moderator of the Java User Group in Bangladesh, where he has organized educational meetups and conferences since 2013. He was named Most Valuable Blogger (MVP) at DZone, one of the most recognized technology publishers in the world. Besides DZone, he is an editor for the Java Queue at InfoQ, another leading technology content publisher and conference organizer, and an editor at Foojay.io, a place for friends of OpenJDK. In addition, he has published five books about the Java programming language in Bengali; they were bestsellers in Bangladesh. He earned his bachelor's degree from the Institute of Information Technology, University of Dhaka, Bangladesh, in Information Technology, majoring in Software Engineering. He currently lives in Toronto, Canada.
Comments (1)
Jan Schäfer
3 years agoThis was proposed by Stephen Colebourne years ago: https://blog.joda.org/2015/08/java-se-8-optional-pragmatic-approach.html