الواجهات الوظيفية القياسية

Written Explanation

The five formats

All of these live in the package java.util.function. You need import java.util.function.*; (or one import per interface) to use them.

The Java documentation describes them in the same terms: a Predicate is a boolean-valued function of one argument, a Function accepts one argument and produces a result, a Consumer accepts one input and returns no result, a Supplier is a supplier of results, and a BiFunction accepts two arguments and produces a result. The package documentation calls the single method of such an interface its functional method.

A trick for remembering the names: Predicate says something is true or false. Function maps an input to an output. A Consumer consumes a value and gives nothing back. A Supplier supplies a value without needing one.

Note that T, R, and U are the type parameters you met in BEG-031: Function<String, Integer> takes a String and returns an Integer. Type arguments must be classes, so you write Integer, not int; the library also has primitive-specialized versions such as IntPredicate and ToIntFunction, which this lesson leaves for later.

One lambda for each

Predicate<String> empty = s -> s.isEmpty();
Function<String, Integer> len = s -> s.length();
Consumer<String> print = s -> System.out.println(s);
Supplier<String> ready = () -> "ready";
BiFunction<Integer, Integer, Integer> add = (a, b) -> a + b;

Using them calls the functional method by name:

empty.test("");        // true
len.apply("lambda");   // 6
print.accept("printed");
ready.get();           // "ready"
add.apply(2, 3);       // 5

The lambda text never mentions test or apply; the interface supplies that name, and the lambda supplies the body.

Methods that accept them

The real power appears when your method takes one of these. Using the generic methods you learned in BEG-031, we can write the building blocks once and reuse them for any type:

static <T> List<T> filter(List<T> in, Predicate<T> p) {
    List<T> out = new ArrayList<>();
    for (T t : in) {
        if (p.test(t)) {
            out.add(t);
        }
    }
    return out;
}

static <T, R> List<R> transform(List<T> in, Function<T, R> f) {
    List<R> out = new ArrayList<>();
    for (T t : in) {
        out.add(f.apply(t));
    }
    return out;
}

static <T> void each(List<T> in, Consumer<T> c) {
    for (T t : in) {
        c.accept(t);
    }
}

static String orDefault(String value, Supplier<String> fallback) {
    return (value == null || value.isEmpty()) ? fallback.get() : value;
}

Look at the last one. Why a Supplier<String> rather than a plain String fallback? Because the supplier is only called when needed. If computing the fallback were expensive (a database read, say), passing a plain value would compute it every time; passing a Supplier computes it only when the value is missing. That ability to delay work is one of the quiet advantages of passing behavior.

You will not write many methods like these in real projects. The JDK already has removeIf, forEach, Comparator.comparing, and, in the next module, filter, map, and forEach on streams, which have exactly the shapes of filter, transform, and each above. Building them once yourself is the best way to understand them.

Combining small pieces

Predicates and functions are objects, so they have methods. The documentation lists, among others, and, or, and negate on Predicate, and andThen on Function:

Predicate<String> longName = s -> s.length() > 4;
Predicate<String> startsWithL = s -> s.startsWith("L");
longName.and(startsWithL);       // both must be true
longName.negate();               // the opposite
Function<String, Integer> lenThenDouble = len.andThen(n -> n * 2);

This is optional vocabulary today. The point: small, named behaviors compose into larger ones, instead of one big lambda with many &&.

Should I write my own interface?

Usually no. If the shape is "one input, boolean out", use Predicate; "nothing in, value out", use Supplier. Write your own functional interface when the standard names would mislead readers (a Discount that reads better than Function<Double, Double>), when the shape is unusual (three inputs), or when the interface is part of your public API and deserves a domain name. Marking your own interface with @FunctionalInterface is optional, but it makes the compiler enforce the one-abstract-method rule and documents your intent.