You make an interesting point about the strategy pattern being used to create functional programming abstractions. Would you say that discrete units of abstraction like SAM interfaces actually encourage a more functional style of programming as opposed to abstract classes which may not be as discrete? If so, and if this is the preferred, better, and more standard approach, would having closures in Java be a natural step forwards for the language?

There are those who want closures and those who don’t, but most of us I think agree that interfaces are good. In terms of SAM interfaces, there is not much difference between them and closures. Both define a single unit of abstraction. But interfaces are considered object oriented whereas closures are not. Surely closures would make for a more pleasant programming experience when used in this way.

In response to 1:
I actually use the predicate on Legs as well as Routes. Therefore the use of generics here is justified. Sample snippet:

new Predicate<Leg>(
 {Leg leg => leg.startsAt(origin)});


In response to 2:
My code does not perform a search on a list of existing routes, but rather on a dynamic iteration of routes that are generated on the fly. The predicate is used to yield eligible routes in real time as they are generated. Having said that, the pattern you describe can still be applied here.

I would also say that if I wrote the code I would possibly do it differently, I say possibly because I haven’t seen the whole example (which is fair enough this is a blog after all). Two things look out of place in the fragment presented are:

1. The use of generics – there is only Route shown, so why not code to Route directly or extend generic interfaces to encode Route – see below

2. eligible and yield have a lot of overlap in their functionality – in normal optimisation and searching algorithms (operations research) you would typically have:

interface Penalty { double cost( T t ); }

/** Route Penalty is the time taken for a given Route */
interface RoutePenalty extends Penalty {}

interface Constraint { boolean isOK( T t ); }

/** Route Constraint is if a given Route is feasible and if it is within user constraints like maximum number of stops */
interface RouteConstraint extends Constraint {}

The search algorithm is usually generic and accepts a Penalty (the cost of the solution, e.g. time of Route) and a List of Constraints (all of which have to be satisfied if the route is OK), so I would be tempted to code the example using the standard searching conventions. The call to optimise would typically be:

/** List of Routes sorted by their penalty */
interface SortedRoutes extends SortedList {}

final Optimiser optimiser = new Optimiser();
optimiser.setPenalty( routePenalty );
optimiser.setConstraints( routeConstraints );
optimiser.setMethod( OptimiserType.GENETIC );
final SortedRoutes possibleRoutes = optimiser.optimise( routes );

The reason for introducing RoutePenalty, RouteConstraint, SortedRoutes, etc. is that they give you somewhere to comment what the penalty, constraints, method of sorting, etc. is for a Route, they also reads a little better in the code.

The above is pseudo code – but hopefully gives an idea of how standard searching algorithms are used.

WarpedJavaGuy – September 8, 2008

Hamlet, my original non-closure version used polymorphism. Hence the reasoning behind the title.

public interface IsRouteOK { boolean test(Route route); }

public class RouteTests {
private IsRouteOK eligible;
private IsRouteOK yield;
private boolean isEligible;

public RouteTests(IsRouteOK yield) {
this(yield, yield);
}

public RouteTests(IsRouteOK eligible, IsRouteOK yield) {
this.eligible = eligible;
this.yield = yield;
}

public boolean eligible(Route route) {
isEligible = eligible.test(route);
return isEligible;
}

public boolean yield(Route test) {
return (isEligible && eligible == yield) ? true : yield.test(route);
}

/* Pre-defined predicates not shown here */

}