I've been developing software with passion for over ten years and for many companies, deeply immersed in the challenging domain of finance. I'm always experimenting on how to improve our craft, in particular with Domain-Driven Design, patterns and agile principles. cyrille is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

A Touch of Functional Style in Plain Java with Predicates – Part 1

11.05.2010
| 11832 views |
  • submit to reddit

You keep hearing about functional programming that is going to take over the world, and you are still stuck to plain Java? Fear not, since you can already add a touch of functional style into your daily Java. In addition, it’s fun, saves you many lines of code and leads to fewer bugs.

What is a predicate?

I actually fell in love with predicates when I first discovered Apache Commons Collections, long ago when I was coding in Java 1.4. A predicate in this API is nothing but a Java interface with only one method:

evaluate(Object object): boolean

That’s it, it just takes some object and returns true or false. A more recent equivalent of Apache Commons Collections is Google Guava, with an Apache License 2.0. It defines a Predicate interface with one single method using a generic parameter:

apply(T input): boolean

It is that simple. To use predicates in your application you just have to implement this interface with your own logic in its single method apply(something).

A simple example

As an early example, imagine you have a list orders of PurchaseOrder objects, each with a date, a Customer and a state. The various use-cases will probably require that you find out every order for this customer, or every pending, shipped or delivered order, or every order done since last hour.  Of course you can do that with foreach loops and a if inside, in that fashion:

public List<PurchaseOrder> listOrdersByCustomer(Customer customer) {
final List<PurchaseOrder> selection = new ArrayList<PurchaseOrder>();
for (PurchaseOrder order : orders) {
if (order.getCustomer().equals(customer)) {
selection.add(order);
}
}
return selection;
}

And again for each case:

public List<PurchaseOrder> listRecentOrders(Date fromDate) {
final List<PurchaseOrder> selection = new ArrayList<PurchaseOrder>();
for (PurchaseOrder order : orders) {
if (order.getDate().after(fromDate)) {
selection.add(order);
}
}
return selection;
}

The repetition is quite obvious: each method is the same except for the condition inside the if clause, emphasized in bold here. The idea of using predicates is simply to replace the hard-coded condition inside the if clause by a call to a predicate, which then becomes a parameter. This means you can write only one method, taking a predicate as a parameter, and you can still cover all your use-cases, and even already support use-cases you do not know yet:

public List<PurchaseOrder> listOrders(Predicate<PurchaseOrder> condition) {
final List<PurchaseOrder> selection = new ArrayList<PurchaseOrder>();
for (PurchaseOrder order : orders) {
if (condition.apply(order)) {
selection.add(order);
}
}
return selection;
}

Each particular predicate can be defined as a standalone class, if used at several places, or as an anonymous class:

final Customer customer = new Customer("BruceWaineCorp");
final Predicate<PurchaseOrder> condition = new Predicate<PurchaseOrder>() {
public boolean apply(PurchaseOrder order) {
return order.getCustomer().equals(customer);
}
};

Your friends that use real functional programming languages (Scala, Clojure, Haskell etc.) will comment that the code above is awfully verbose to do something very common, and I have to agree. However we are used to that verbosity in the Java syntax and we have powerful tools (auto-completion, refactoring) to accommodate it. And our projects probably cannot switch to another syntax overnight anyway.

Predicates are collections best friends

Didn't find any related picture, so here's an unrelated picture from my library

Coming back to our example, we wrote a foreach loop only once to cover every use-case, and we were happy with that factoring out. However your friends doing functional programming « for real » can still laugh at this loop you had to write yourself. Luckily, both API from Apache or Google also provide all the goodies you may expect, in particular a class similar to java.util.Collections, hence named Collections2 (not a very original name).

This class provides a method filter() that does something similar to what we had written before, so we can now rewrite our method with no loop at all:

public Collection<PurchaseOrder> selectOrders(Predicate<PurchaseOrder> condition) {
return Collections2.filter(orders, condition);
}

In fact, this method returns a filtered view:

The returned collection is a live view of unfiltered (the input collection); changes to one affect the other.

This also means that less memory is used, since there is no actual copy from the initial collection unfiltered to the actual returned collection filtered.

On a similar approach, given an iterator, you could ask for a filtered iterator on top of it (Decorator pattern) that only gives you the elements selected by your predicate:

Iterator filteredIterator = Iterators.filter(unfilteredIterator, condition);

Since Java 5 the Iterable interface comes very handy for use with the foreach loop, so we’d prefer indeed use the following expression:

public Iterable<PurchaseOrder> selectOrders(Predicate<PurchaseOrder> condition) {
return Iterables.filter(orders, condition);
}

// you can directly use it in a foreach loop, and it reads well:
for (PurchaseOrder order : orders.selectOrders(condition)) {
//...
}

Ready-made predicates

To use predicates, you could simply define your own interface Predicate, or one for each type parameter you need in your application. This is possible, however the good thing in using a standard Predicate interface from an API such as Guava or Commons Collections is that the API brings plenty of excellent building blocks to combine with your own predicate implementations.

First you may not even have to implement your own predicate at all. If all you need is a condition on whether an object is equal to another, or is not-null, then you can simply ask for the predicate:

// gives you a predicate that checks if an integer is zero
Predicate<Integer> isZero = Predicates.equalTo(0);
// gives a predicate that checks for non null objects
Predicate<String> isNotNull = Predicates.notNull();
// gives a predicate that checks for objects that are instanceof the given Class
Predicate<Object> isString = Predicates.instanceOf(String.class);

Given a predicate, you can inverse it (true becomes false and the other way round):

Predicates.not(predicate);

Combine several predicates using boolean operators AND, OR:

Predicates.and(predicate1, predicate2);
Predicates.or(predicate1, predicate2);
// gives you a predicate that checks for either zero or null
Predicate<Integer> isNullOrZero = Predicates.or(isZero, Predicates.isNull());

Of course you also have the special predicates that always return true or false, which are really, really useful, as we’ll see later for testing:

Predicates.alwaysTrue();
Predicates.alwaysFalse();

Where to locate your predicates

I often used to make anonymous predicates at first, however they always ended up being used more often so were often promoted to actual classes, nested or not.

By the way, where to locate these predicates? Following Robert C. Martin and his Common Closure Principle (CCP) :

Classes that change together, belong together

Because predicates manipulates objects of a certain type, I like to co-locate them close to the type they take as parameter. For example, the classes CustomerOrderPredicate, PendingOrderPredicate and RecentOrderPredicate should reside in the same package than the class PurchaseOrder that they evaluate, or in a sub-package if you have a lot of them. Another option would be to define them nested within the type itself. Obviously, the predicates are quite coupled to the objects they operate on.

Resources

Here are the source files for the examples in this article: cyriux_predicates_part1 (zip)

In the next part, we’ll have a look at how predicates simplify testing, how they relate to Specifications in Domain-Driven Design, and some additional stuff to get the best out of your predicates.

 

From http://cyrille.martraire.com/2010/11/a-touch-of-functional-style-in-plain-java-with-predicates-part-1/

Published at DZone with permission of cyrille martraire, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Alessandro Santini replied on Fri, 2010/11/05 - 11:01am

Excellent post.

Subhash Chandran replied on Fri, 2010/11/05 - 11:06pm

Thanks for introducing this important concept.

Igor Laera replied on Sun, 2010/11/07 - 7:17pm

 

Since I'm currently designing a new api, this comes in a very good time.
It's very hard to find this type of interesting, modern ideas in any current book.
I'm looking forward to read more articles about any other cross-language-concepts.

Perfect!

 

Liu Nathan replied on Sun, 2010/11/07 - 9:29pm

Maybe lambdaj(google code) is another alternative.

Gérald Quintana replied on Mon, 2010/11/08 - 5:15am

Nice article, I am fond for predicates as well. I regret they are not part of Java SE APIs.

Using static imports, you can make things more readable:

import static Predicates.*;
Collection<Order> filteredOrders=filter(orders, not(or(equalTo(0), isNull())));

JUnit 4 has something called Hamcrest which is similar to Apache Collections and Google Collection but oriented for writing assertions on collections.

cyrille martraire replied on Mon, 2010/11/08 - 6:32am

Thanks for the complementary feedbacks!

@Liu, yes lambdaj (http://code.google.com/p/lambdaj/) has a similar objective and goes further into a fluent interface style, however I've never tried it myself.

@Gérald, absolutely, static imports can help a lot unclutter the code. For the code examples in this article however I prefered to show the class for clarity.

The part 2 with more advanced notions is almost ready for publication.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.