在应用程序接口中使用java.util.Date的好理由
在API中使用Date类(例如，在员工出生日期字段中)而不是Long或long有什么特殊的原因吗？
在：java-date-vs-calendar中有一些关于这方面的讨论，但我特别想知道使用Date是否有任何理由，因为long (或Long)看起来要简单得多。
当然，我会使用TimeZone和SimpleDateFormatter在图形用户界面中解析和显示日期，也许还会使用Calendar来执行操作，但在这个问题中，我只关心日期在数据模型/API中的存储和表示。
Date更新：我不选择的一个原因是它是可变的。因此，如果我在我的API中公开了一个日期，调用者可以调用setTime(long)，这似乎违反了基本的封装。对我来说，这似乎超过了使用Date提供的更清晰的好处，因为我可以只调用long属性timeInMillisecondsSinceEpoch并将相同的信息传递给调用者。
回答 4
Stack Overflow用户
发布于 2011-06-07 23:25:39
Date类是应用程序接口的一部分，因此是一个有效的选项，如果它适合您的目的的话。其中有许多被Calendar类替换的已弃用方法，因此请确保避免使用这些方法。
答案将取决于你需要完成什么。如果你只需要按日期排序，一个long就足够了。Date值将为其添加一些可读性，但不会增加更多功能。使用Date也不会有坏处，因此应该考虑可读性因素。
如果字段将是私有的，您可以将其实际存储为一个长整型，并拥有一个使用Date的getter和setter：
private long mDOB;
public Date getDOB () { return new Date(mDOB);}
public void setDOB (Date dob) { mDOB = dob.getTime(); }Stack Overflow用户
发布于 2011-06-07 23:07:29
如果您在API中使用整数来表示日期，您将添加额外的、不必要的复杂性层，这将需要额外的文档，并使您的API更难使用。
通过使用整数，您必须让客户端知道基准日期是什么，您正在测量的是什么(例如秒、毫秒、分钟等？)并强制客户端进行转换。在API中保留Date对象可以使其更简单、更友好。除非，无论出于什么原因，存在非常严重的性能影响，我建议将日期保留在您的API中，即使您需要在内部进行更多的编码。这是使一个好的API成为一个好的API的原因之一……而不是让你的客户如履薄冰。
Stack Overflow用户
发布于 2011-06-07 23:07:51
就我个人而言，尽管Java中的日期和时间API很糟糕，但我倾向于使用Date。它只是有更多的语义价值。此外，您不必猜测它是秒还是毫秒。
https://stackoverflow.com/questions/6267228
复制相似问题