编写NullPointerException,JAVA 8的多个检查的替代方法

时间:2018-08-31 21:15:57

标签: java java-8 null conditional optional

在JAVA 8中还有更好的方法编写代码吗?

    if (info1 != null && info1.getId() != null && info1.getPartyNumber()!= null) {
        billing.setSenderId(info1.getId());
        billing.setSenderNumber(info1.getPartyNumber());
    }
    if (info2 != null && info2.getId() != null && info2.getPartyNumber()!= null) {
        billing.setReceiverId(info2.getId());
        billing.setSellerNumber(info2.getPartyNumber());            
    }

    ..
    ..

先谢谢了。 注意:我调查了Optional.ofNullable(),但不确定这是否真的可以帮助进行多次检查?

4 个答案:

答案 0 :(得分:5)

这是我能想到的最好的。我会让你决定它是否更干净:

Optional<Info> oInfo1 = Optional.ofNullable(info1);
oInfo1.map(Info::getId).ifPresent(billing::setSenderId);
oInfo1.map(Info::getPartyNumber).ifPresent(billing::setSenderNumber);

Optional<Info> oInfo2 = Optional.ofNullable(info2);
oInfo2.map(Info::getId).ifPresent(billing::setReceiverId);
oInfo2.map(Info::getPartyNumber).ifPresent(billing::setSellerNumber);

请注意,这与原始设置略有不同,因为它可能会设置一个字段,即使另一个字段为空。

答案 1 :(得分:4)

如果您想用Optional重写它,它可能看起来像这样:

Optional.ofNullable(info1)
.filter(i -> i.getId() != null)
.filter(i -> i.getPartyNumber() != null)
.ifPresent(i -> {
  billing.setSenderId(info1.getId());
  billing.setSenderNumber(info1.getPartyNumber());
});

编辑

仅当info1不是null并且指定为Optional.filter参数的所有条件都匹配时,我们才会处理info1 != null。因此,仅在info1.getId() != nullinfo1.getPartyNumber() != nullConsumer的情况下,info2将被执行。这是编码多种检查的一种替代方法。它可以执行您的代码。

同样的方法适用于Optional

编辑

request.setAttribute()的流利的API与多行符号相结合将每个条件分解为一条单独的行。 IMO使得代码易于阅读,因此易于理解。它尽可能地保持了原始代码的简洁性和清晰度,并且仍然具有相同的行为。

答案 2 :(得分:0)

如果您在源代码中复制代码,则应三思而后行。我认为您的测试很好,但我会为此提供一种方法,因此您的代码如下所示:

if(isComplete(info1) { .... } 如果(isComplete(info2) { .... }

答案 3 :(得分:0)

如果您的多次重复遵循一个确切的模式(例如,每个奇数重复均设置为receiver,否则为sender),或者此模式可以提取为Set<Integer>,则可以使用{{ 1}},其中键是Map<Integer, Info>的ID,请对其进行迭代,并仅设置所选项目。

Info

解决方案会有所不同,具体取决于可能的设置数量以及List<Info> list = ... // List of Info Map<Integer, Info> map = list.stream() // Stream .filter(Objects::nonNull) // Filter null values .filter(i -> i.getId() != null && i.getPartyNumber() != null) // Filter null fields .collect(Collectors.toMap(Info::getId, i -> i)); // Collect to Map<Integer, Info> for (int i=0; i<10; i++) { // The number of repetitions if (map.containsKey(i)) { // If the ID was not filtered Info info = map.get(i); // Get the Info // Here the pattern comes if (i % 2 == 0) { // you can either compare with a // predefined Set of IDs billing.setSenderId(info.getId()); billing.setSenderNumber(info.getPartyNumber()); // Sender } else { billing.setReceiverId(info.getId()); // Receiver billing.setSellerNumber(info.getPartyNumber()); } } } sender。另外,模式的计算可能基于不同的逻辑-我建议针对ex进行验证。 receiver将包含适合设置为发送者的ID,接收者和其他可能性也一样。

  • 专家
    • 无论迭代了多少Set<Integer> senders,解决方案的长度都保持不变(除了将所有Info收集到输入Info之外)。
    • 避免膨胀代码和重复。
  • 缺点
    • 您必须考虑计算和逻辑以区分要设置的内容。
    • 看起来可能凌乱且难以阅读。