小编use*_*236的帖子

当您为接口中的"未定义"定义枚举时,是否应该

• 为此定义一个单独的枚举值,或
• 只为这些情况使用enumValue = null？

例如,

serviceX.setPrice(Price priceEnum)

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN
}

和priceEnum.UNKNOWN需要的时候

要么

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE
}

和priceEnum = null需要吗？

对此有一点争论.想到的一些要点:

• 使用Price.UNKNOWN保存一些"if(price == null)"代码.您可以在单个switch-case中处理Price x的所有值
• 根据视图技术,可能更容易本地化Price.UNKNOWN
• 使用Price.UNKNOWN类型导致代码中的"幻数"问题,IMO.这里我们有Price.UNKNOWN,其他地方可能是Color.UNDEFINED,Height.NULLVALUE等
• 使用priceValue = null与在Java中处理其他数据类型的方式更加一致.我们有Integer i = null,DomainObject x = null,String s = null也是未知值,不是吗？
• Price.UNKNOWN强制您决定是否允许所有用例的空值.我们可能有方法Price getPrice()可能返回Price.UNKNOWN和setPrice(价格p),不允许接受Price.UNKNOWN.由于Price.UNKNOWN始终包含在枚举值中,因此这些界面看起来有点不洁净.我知道priceValue = null有同样的问题(你不能在接口中定义是否接受null)但它感觉有点清洁,有点误导(？)

我们发布了1.0版并继续在trunk中开发2.0.我们为与发布版本相关的错误修复创建了分支/ 1.0.

计划是:

• 继续在trunk/2.0中继续开发
• trunk /包含不要合并到branches/1.0的新功能,因此trunk不会合并到branches/1.0中
• 当在已发布的应用程序中发现错误时,修复程序将被转换为branches/1.0.当修订集发布到生产中时,branches/1.0被复制到tags/1.0.x,branches/1.0被合并到trunk /
• 想法是颠覆合并跟踪应该跟踪变化,这样当我们将1.0.4修复合并到trunk时,会自动跳过1.0.3修复

这种方法有什么问题吗？将颠覆合并跟踪跟踪变化好吗？我还没有在实践中尝试过这个,并且大多数示例都是这样做的(从主干​​到分支合并,我不想要,因为1.0修复中不需要大多数2.0开发).合并重新融合是否适合这种方式？