检查对象的某些字段是否为空

Question

我遇到了一个错误设计的带有 34 个参数的 java 对象的问题。

该对象有时可以有 3 个填充值，而其他对象必须为 null 。在第二种情况下，15 个字段被填充，其他字段必须为空等等......

我现在无法更改此对象，因为它链接到存储库模型。

有没有办法检查字段名称列表是否为空？我还考虑创建一个子对象来创建 isEmpty() 方法，以便分割支票的大小。

例如这个类“Guy”：

public class Guy {
    private String name;
    private String haveCar;
    private String carBrand;
    private String isRentedCar;
    private String rentCarCompany;

    public checkGuy(Guy guy){
        if(guy.getHaveCar.equals("YES")){
            // check if car brand exist
            if ( guy.isRentedCar.equals("YES")){
                // check if rent car company in db ...
            }
        }
    }
    
    // ...
}

当有人发布这个对象时，我想避免保存这个对象：

public class Guy {
    private String name;
    private String haveCar;
    private String carBrand;
    private String isRentedCar;
    private String rentCarCompany;

    public checkGuy(Guy guy){
        if(guy.getHaveCar.equals("YES")){
            // check if car brand exist
            if ( guy.isRentedCar.equals("YES")){
                // check if rent car company in db ...
            }
        }
    }
    
    // ...
}

Answer 1

这是一个很好的问题，因为这种情况经常发生，很多人不知道如何处理。

这就是我认为你问的问题。我们有一个我们无法控制的预先存在的类。

public class TerribleClass {
  // Bad design choices live here :)
}

我们希望我们的API 能够智能地使用这个类。有很多枪械和滥用该类的方法，而这个写得不好的类并不能帮助我们处理这些问题。

那么，答案就是尽可能TerribleClass少地处理。您自己的代码应该在 99% 的时间处理包装类，并且仅TerribleClass在绝对必要时才处理。

public class GoodWrapper {
  private TerribleClass terribleObject;

  public GoodWrapper(TerribleClass terribleObject) {
    // Validate all preconditions here.
    if (terribleObject.isInvalidState()) {
      throw new IllegalArgumentException("Found a terrible object in a bad state");
    }
    this.terribleObject = terribleObject;
  }

  // Now write getters for all of the data we can safely access.
  // We're doing it right this time, so make sure any functions that
  // can return null are documented as such. Consider using @Nullable
  // and @NotNull annotations. 

  public int getValueFromTerribleClass() {
    return terribleObject.whatever;
  }

}

现在您提到通过 POST 请求从网络获取此信息。如果您的代码当前看起来像

public TerribleClass makePostRequest(...) {
  TerribleClass result = RequestsLibrary.post(...);
  return result;
}

现在你改为写这个。

public GoodWrapper makePostRequest(...) {
  TerribleClass result = RequestsLibrary.post(...);
  return new GoodWrapper(result);
}

唯一需要处理那个混乱的、未经检查的对象TerribleClass的函数是makePostRequest. 每个调用你的函数的人都会得到一个友好的对象，其不变量都会被检查。

保护您自己和下游用户免受不良代码侵害的方法就是使自己免受不良代码的影响。类设计不好？编写一个包装器并仅公开它。是否有返回错误类的 API 函数？创建一个返回您好的实例的适配器类。让你的所有业务逻辑都能看到漂亮的对象，最坏的情况是，你有一些包装器必须做出混乱的决定。但所有的混乱都集中在一个地方。