使用Custom Optional Class替换findAny或findFirst中的返回可选实例

Question

我不知道是谁负责这种工作,但对我来说,Javas Optional似乎还没有为制作做好准备.似乎Java Creators只是分层来完成工作,结果是一个没有准备好的可选类,缺少很多功能.

例如,考虑ifPresent方法.返回类型是void,但它可能是一个实例,只是在流框架中有类似peek的东西.把这个返回到一个方法中并不是什么大不了的事情,但不这样做意味着关于可选的思考不是生产就绪的.

另一个例子是缺少经过检查的方法,认为映射或过滤可能会引发异常,导致很多try catch样板.相反,他们只是添加了一个UncheckedIOException.样板仍然存在.我的意思是添加检查方法也是如此困难？

A可以给你更多的例子,但我不想把我的精力和时间投入到非完整的类中,比如可选的.我开始创建一个可选的替代品,我将来可能会将其作为一个开源项目发布.我实现的唯一缺点是可以将我的可选类与流框架结合起来,其中findAny或findFirst等方法返回我想要替换的Optional类型.我需要面对的这个问题,因为当然可选的需要是最终的.

我不知道什么是最好处理这种情况所以我希望这里有人可以给我一个很好的提示.

提前致谢.

编辑:我的确觉得这里有些人懒得看我的帖子,所以我想把事情搞清楚.

如果我说ifPresent应该返回这个当然我不能意味着Optional持有的值.它意味着"this"实例,以便您可以使用下一个命令进行链接,就像在流框架中查看一样.

public void ifPresent(Consumer<? super T> consumer) {
    if (value != null)
        consumer.accept(value);
}

这是当前在Java8中使用的Optional的原始代码.如果您对该功能有所了解,可以这样写:

public OptionalReplacement<T> ifPresent(Consumer<? super T> consumer) {
    requireNonNull(consumer);
    if (isPresent()) {
        consumer.accept(value);
    }
    return this;
}

然后你就可以写出像

OptionalReplacement.of(nullable)
    .ifPresent(notNull-> System.out.println(notNull))
    .ifPresent(notNull-> System.out.println(notNull))

没有理由将ifPresent视为无效并返回,这使您可以更灵活地进行链接.你能用当前的可选类进行那种链接,不!

下一个主题是已检查的例外.因为有些人没有幻想,我会给你一个处理检查异常的可能地图的例子.

@FunctionalInterface
public interface CheckedFunction<T, R, E extends Exception> {
    R apply(T t) throws E;
}

public <U, E extends Exception> OptionalReplacement<U> checkedMap(Class<E> exceptionClass, CheckedFunction<? super T, ? extends U, E> mapper) throws E {
    requireNonNull(exceptionClass);
    requireNonNull(mapper);
    if (!isPresent())
        return empty();
    else {
        return OptionalReplacement.of(mapper.apply(value));
    }
}

所以你能够写出类似的东西

OptionalReplacement.of(nullable)
        .checkedMap(IOException.class, notNull -> {
            throw new IOException();
        });

这比做得更有意义

    Optional.of(nullable)
            .map(notNull -> {
                try {
                    throw new IOException();
                } catch (IOException e) {
                    return null;
                }
            });

同时评论评论中提到的投票.投票既好又好,但人民群众从来都不是质量的指标.我对于愚蠢的问题得到了很好的投票,而且我对智能问题投了反对票,所以我很好.

用户应该更多地考虑我试图在这里面对的问题,而不是分散不重要的东西.

Answer 1

例如,考虑ifPresent方法.返回类型是void,但它可能是一个实例,只是在流框架中有类似peek的东西.把这个返回到一个方法中并不是什么大不了的事情,但不这样做意味着关于可选的思考不是生产就绪的.

Optional在那里抽象出null价值.它做得很好:如果value是null,你将无法value从任何方法中获得.

现在,ifPresent如果value是,应返回哪个值null？这不可能value因为这将打破主要原则Optional.那应该归还什么？选项包括:

• 提供像orElse和喜欢的价值;
• 有void返回类型.

ifPresent(Consumer<? super T> consumer, T other) 很丑,所以设计选择很明显.

接下来,如果您将其提供给消费者,为什么还需要返回值？为什么你不能做任何你想做的消费者的价值？

另一个例子是缺少经过检查的方法,认为映射或过滤可能会引发异常,导致很多try catch样板.相反,他们只是添加了一个UncheckedIOException.样板仍然存在.我的意思是添加检查方法也是如此困难？

不可能.假设您的映射函数抛出一些已检查的异常.您如何期望此Optional.map签名的异常出现在签名中？选项包括:

• throws Exception用try/ catch块污染一切;
• map(mapper, exceptionHandler) 这不是更好.

因此整个lambdas事物只能在未经检查的异常中起作用,其他一切都会产生非常难看的代码.

A可以给你更多的例子,但我不想把我的精力和时间投入到非完整的类中,比如可选的.

Optional在Java 8中与OptionalGuava 非常相似,它已存在很多年并且受到好评.

最糟糕的设计决策Optional可能是get导致很多人编写if (o.isPresent()) { T value = o.get(); ... }代码类型的方法.

你可能想重新考虑你的判断Optional.

我开始创建一个可选的替代品,我将来可能会将其作为一个开源项目发布.

一个独立的重新想象的重新实现Optional将是非常无用的.而且你无法替换OptionalJava集合框架所使用的.

我不知道什么是最好处理这种情况所以我希望这里有人可以给我一个很好的提示.

一个很好的提示是询问您遇到的具体问题Optional以及如何在代码中更好地解决这些问题.正如你从downvotes中看到的那样,一个更好,更尊重的语气也不会造成任何损害.