Если бы я написал интерфейс Predicate
, я бы хотел закодировать в интерфейсе тот факт, что это просто функция, которая возвращает примитивное boolean
, например:
@FunctionalInterface
public interface Predicate<T> extends Function<T, Boolean> {
boolean test(T t);
@Override
default Boolean apply(T t) {
return Boolean.valueOf(test(t));
}
}
Мне было интересно, есть ли веская причина, по которой дизайнеры Java 8 API решили полностью отделить Predicate
от Function
? Есть ли какие-то доказательства того, что они подумали об этом и решили против этого? Я полагаю, что аналогичный вопрос касается всех других "специальных" функциональных интерфейсов, таких как Consumer
(может быть Function<T, Void>
), Supplier
(Function<Void, T>
) и примитивные функции, такие как IntFunction
(Function<Integer, T>
).
Я не очень глубоко и тщательно обдумывал все последствия этого, поэтому я, наверное, что-то упустил.
РЕДАКТИРОВАТЬ: Некоторые ответы подчеркивают семантическое различие между применением и тестированием. Я не говорю, что не ценю это различие, и я согласен, что это различие полезно. Я не понимаю, почему Predicate
, тем не менее, также не является Function in
же, как, например, List
- это Collection
или Double
- это Number
, которое является Object
.
Если бы Predicate
(и все другие специальные универсальные функциональные интерфейсы, такие как Consumer
, Supplier
, IntUnaryOperator
и т.д.) Имели такое отношение с Function
, это позволило бы использовать его там, где ожидается параметр Function
(что приходит на ум, это композиция с другие функции, например, вызов myFunction.compose(myPredicate)
или чтобы избежать написания нескольких специализированных функций в API, когда такой реализации автоматического (не) бокса, как описано выше, будет достаточно)
РЕДАКТИРОВАТЬ 2: Глядя на лямбда-проект openjdk, я обнаружил, что примитивные функциональные интерфейсы использовались для расширения Function
вплоть до этой фиксации от Brian Goetz 2012-12-19. Я не смог найти конкретные причины для изменений ни в одном из списков рассылки lambda-dev или JSR.