Is it good to give null a meaning along with two Boolean value to represent ternary balue in filtering?

Question

One of my colleague decided to declare some API code like this:

public interface Filter<T> {
    /**
     * Test whether the given input is valid.
     * @param input the input
     * @return null for neutral, {@code Boolean.TRUE} for accepted and {@code Boolean.FALSE} for rejected.
     */
    Boolean apply(T input);
}

The idea generated a war on the IRC. While some is advocating the Boolean approach, the others think it bad practice and should use an enum of three elements to represent the indiviual state, like this:

public interface Filter<T> {
    Result apply(T input);
    enum Result {
        ACCEPT, UNKNOWN, DENIED;
    }
}

So, in terms of performance, readability, maintainability or, well, if it really matters, less code, what is the best practice in production?

EDIT: Here, ACCEPT, UNKNOWN( or NEUTRAL), REJECT( or DENY) is what @erickson means. If you gpt confused, please refer to his anwser if you get confused.

In respond to the "put on hold", I clarify that my question mainly concerns on: * Is there a clear convention of this?* this is the reason for accepted anwser

Answer 1

The principle of least astonishement recommends using booleans only for true/false, and enums for anything else, such as { Trueish, Falsish, Undecideish }. Additionally, unlike Boolean, you can actually document the enum's values so that it is immediately evident what that MyEnum.Truieish actually means in the context of your application.

Answer 2

Use of a ternary value is well established in filtering applications. More often, you'll see the options named ACCEPT, DENY, and NEUTRAL. This is extremely useful in short-circuiting filter chains. However, these mechanisms don't use null to represent NEUTRAL.

Using a 3-valued enum instead gives you more utility.

Values can have methods. The implementation can be different for each value, or it could be a common implementation that works sort of like the Visitor pattern. If you use Boolean and null, you can't provide custom methods, and even if you could extend Boolean, you can't extend null.

You can use enum values as keys in maps more readily than null, which isn't accepted by many Map implementations. This can be useful for keying handlers by status.

You can use enum values in switch statements, and the compiler helps to ensure that you've covered all the options. If you fail to handle true, false, and null in a cascade of if-else-if-else, the compiler won't notice.

Finally, you should use the @FunctionalInterface annotation on your functional interfaces. It will cause the compiler to complain if you carelessly add another abstract method, or do anything else that makes your type ineligible for use functionally.

Answer 3

As a general programming advice, at least for Java & Scala, Never, ever, ever, use null as a return value, especially if you are coding public API.

Basically if you do it, you are going to violate the contract (the interface) you expose to the consumers of your method. The interface proudly states "there will be a value, and it will be a Boolean !" but instead your implementation will LIE ! WRONG ! If you want to expose the absence of something, just go for Optional (java 8 or Guava !). It might make your code a bit less-readable but it will safe, and testable :-)

To come back to your question, the enum sounds a good and clean solution. It will be meaningful for whom consumes the API and it will improve testability and readability !