更聪明的二传手?好主意还是坏主意?

时间:2009-05-14 14:57:54

标签: java gwt

在GWT解决方案中。 (所以这是java代码,然后编译为javascript)。 当然有一些课程。

在字符串字段上设置Null的setter是否是个好主意?

类似这样的事情

public void setSomeField(String someField){
  if (null != someField)
    this.someField = someField;
  else
    this.someField = String.Empty;
}

这是一个好主意还是坏主意?在一个人有它将使编码更容易,因为我不必检查null,另一方面它会让我可能忘记我必须为其他字符串执行此操作。

思考? 谢谢

6 个答案:

答案 0 :(得分:5)

我说如果你的应用程序需要这样的逻辑,那么setter就是放置它的地方。对私有var进行get / set包装的主要原因是能够在访问周围放置逻辑。

要回答默认或不默认的问题: 在我的应用程序中,由于显示原因,它使得有一组属性回退到string.empty。虽然人们可能会认为视图应该涵盖这些可能性并检查空值并且不显示任何内容,但是在我的页面上对每个属性进行检查是非常膨胀的。

这就是我开始实施SafeXX属性的原因。所以说我的'myObj.Name'可能有一个空值,还有一个属性'myObj.SafeName'在getter中捕获了null并且返回了一个string.empty。小命名约定表明它不是常规的吸气剂。

答案 1 :(得分:3)

这是需要考虑的事情。您是否希望此单元测试通过或失败?:

yourClass.setSomeField(null);
assertNull(yourClass.getSomeField());

如果要将空值更改为空字符串并在getSomeField中返回该字符串,则客户端现在必须在测试时检查两个条件...一个字符串和一个空字符串。没什么大不了的,但是如果你在课堂上有二十个String属性会发生什么......你可能最好尝试在所有的setter中保持一致,如果你不是,那么理由应该更多显而易见的只是文件说的那样。

有关getter和setter的某些约定;某些期望。如果我在一个对象上调用一个setter,那么我通常会期望getter返回我设置的内容。我不希望它返回我传递的内容的一些表示,这对于类在内部工作更方便。我不关心班级的内部,也不想。

答案 2 :(得分:1)

如果出于正当理由null确实应该更改为""(例如,它可能意味着“我不关心”且默认值可能是""),请执行为它(但记录它)。

否则,就像刚刚抓到NullPointerException并试图以这种方式修复它一样,不要这样做。如果调用者使用明显无效的值,则应尽快引发异常,以便调用者在可能完全不相关的组件中出现灾难性的,无法解释的错误之前注意到问题并修复它。

答案 3 :(得分:0)

通常,检查空值不是一个好主意,因为调用者(调用setter的人)可能真的想将值设置为null。

假设您使用以下方法查询“someField”:

select * from ... where someField is null

如果将其设置为空字符串,则上述查询将失败。

答案 4 :(得分:0)

如果您不希望将字段设置为null,则不要将其设置为null。

如果您无法控制执行该设置的代码,这可能是一个好主意,但如果您这样做,最好在源代码处理问题,而不是像这样处理。

答案 5 :(得分:0)

这很难回答。在第一次看来它似乎使用得更好,因为你不必一直检查null。但是你失去了null的质量,这意味着什么都没有分配。如果你做String.Empty,如果有人给你一个String.Empty作为参数,你已经有歧义。也许没关系。

我个人(如果有的话)不会在二传手中做到这一点。在你的类中,null应该有自己的值。如果你是为了方便一个吸气剂

return (this.someField != null) ? this.someField: String.Empty;

会做的。你会在内部保持null来处理,但外部有一个更方便的方法。

一般而言,我个人不会这样做。它起初看起来很好,并且在以后会使很多事情变得更难。