java - 当使用旧版 API 时，为什么 Date 比 Calendar 更适合属性输入？

Question

首先，请注意此问题不是此问题的重复: Java Date vs Calendar 。我的问题更加具体。引用的问题询问“什么”(或“哪个”)，但我已经知道“什么”并且正在问“为什么”。

我所在的团队致力于为客户增强现有 Java 项目。该 Java 项目使用 java 6，并且没有 Joda Time 作为依赖项。经过询问，似乎添加 Joda Time 或升级到 Java 8 都不是选项。

因此，当将日期/时间表示为对象中的字段时，我们必须使用 Calendar 或 Date 来进行属性输入。该项目的遗留代码中散布着使用日历来表示日期/时间字段的对象——我们永远不会操作这些字段(例如添加或减去时间单位等)。我知道这是不好的做法，因为日历是一个更复杂的对象，而日期更简单并且效果也一样。 (当然，我知道两者从根本上来说都是长纪元的包装器，都是可变的，并且设计得很糟糕，但同样，这是我们唯一的两个选择。)

换句话说，像这样的对象:

public class Reservation {

    private Guest guest;
    // Set only once, never used for calculations
    private Calendar dateReserved;
    ...
}

应该是这样的:

public class Reservation {

    private Guest guest;
    // Set only once, never used for calculations
    private Date dateReserved;
    ...
}

然后我注意到，在为新功能添加新对象时，我的团队遵循使用日历而不是日期的相同约定。当我提出这个问题时，得到的答复是最好使用日历，因为它可以做更多事情，并且不像 Date 那样具有所有这些已弃用的方法。

我知道这个推理过于简单化了。我还看到 this answer 对于更广泛的使用问题表达了相同的观点，即日历不应该用于属性类型。但是，答案并未包含太多关于为什么不应首选日历的解释。

所以我已经知道“什么”了。但我试图向我的团队说明这一点，所以我的问题是，“为什么”？为什么在属性输入时应优先选择“日期”而不是“日历”？使用 Calendar 而不是 Date 进行属性输入有哪些缺点？

Answer 1

我同意 Jon Skeet 关于日历系统和时区的评论，并且我认为你的前提从根本上来说是有缺陷的。日期并不比日历更好。如果您永远不会比较时间，或者永远不会在不同时区有两个日期，那么当然，较小的占用空间可能会很好，我想，但在这一点上，只需使用长整型和 Unix 时间戳。日历是迄今为止更好的对象模型，毕竟，如果您绝对需要它，您可以从中获取 Date 对象。