在使用BooleanSupplier的时候，有时候感觉BooleanSupplier并不是特别需要:
String s1 = "ABC";
String s2 = "ABC";
BooleanSupplier stringEquals = () -> s1.equals(s2);
System.out.println(stringEquals.getAsBoolean());
Vs
System.out.println(s1.equals(s2));
这里感觉使用s1.equals(s2)更为简洁.
在Stackoverflow中并没有直接说明BooleanSupplier, 而是使用Supplier的一个应用场景来解释了这个问题. Debug日志的输出
通常，我们对debug日志的输出都是下面这段代码, 从而避免 veryExpensive()操作在debug+日志级别的时候执行.
if (logger.isDebugEnabled()) {
logger.debug("veryExpensive() returned: " + veryExpensive());
}
如果项目中有很多debug级别的日志，就会出现很多上面的 if ... debug 的代码块.
这种代码块多了，就会感觉不简洁, 就会产生一种封装的冲动, 将if(logger.isDebugEnabled())逻辑封装到一个方法中,得到debug(String message)方法.
那么上面的代码就变成了下面这样:
logger.debug("veryExpensive() returned: " + veryExpensive());
但是这里就带了一个新的问题, 在debug+日志级别下执行了veryExpensive()操作. 这个操作其实是不需要执行的.
如果我们封装的方法支持Supplier参数，那么就可以解决上面这个问题.
logger.debug(() -> "veryExpensive() returned: " + veryExpensive());
在logger.debug中只有条件logger.isDebugEnabled()成立的时候才会调用supplier.get()方法执行veryExpensive . 从而避免了在debug+日志级别的时候执行了veryExpensive
总结: Supplier 提供了一个延迟执行得到结果的能力, 类似上述的日志打印的场景, 如果只是在某个可选的条件下执行某个操作得到结果就可以使用Supplier . 当然, 不是可选条件, 想要在使用的时候再得到结果也可以使用Supplier<?>.
Refrences:
1. stackoverflow关于BooleanSupplier的讨论 stackoverflow.com/questions/4…
