代码之家 › 专栏 › 技术社区 › sleske

为什么JavaDealAPI(JavaUTLDATE,.NETURLY)如此混乱?

api-design date java

sleske · 技术社区 · 15 年前

正如大多数人现在所知的那样,Java API用于处理日历日期(具体地说是类)。 java.util.Date 和 java.util.Calendar )真是一团糟。

在我的头顶上:

日期是可变的
日期表示时间戳,而不是日期
无法在日期组件(日、月、年…)和日期之间轻松转换
日历使用起来笨重,它试图将不同的日历系统组合成一个类。

This post 总结得很好,而且 JSR-310 同时也解释了这些问题。

现在我的问题是:

这些类是如何进入Java SDK的?这些问题中的大多数似乎相当明显(尤其是日期是可变的),应该很容易避免。那是怎么发生的?时间压力?或者这些问题仅仅在回顾时是显而易见的吗?

我意识到这并不是一个严格的编程问题,但我会发现理解API设计如何会出错是很有趣的。毕竟,错误总是一个很好的学习机会(我很好奇)。

4 回复 | 直到 9 年前

sleske 9 年前

有人说得比我说得好:

等级 Date 表示特定的时间瞬间,毫秒精度。这门课的设计是一个非常糟糕的笑话-一个清醒的即使是优秀的程序员也会搞砸的例子。大多数方法日期现在已被弃用,替换为以下类中的方法。

等级 Calendar 是一个抽象类,用于在 日期 对象和一组整型字段,如年、月、日和小时。

等级 GregorianCalendar 是唯一的子类 历法 在JDK中。它将日历系统的日期字段转换为常用。Sun从Taligent-A获得了这批设计过度的垃圾的许可证。一个让人清醒的例子,说明普通程序员是如何搞砸的。

从 Java程序员常见问题解答 由彼得·范德林登于1998年10月7日发布的版本-但这部分内容已从后来的版本中删除。

至于可变性,许多早期的JDK类都会受到影响。( Point ,请 Rectangle , Dimension ,……)我听到一些人说,错误的优化。

其思想是希望能够重用对象( o.getPosition().x += 5 )而不是创建副本( o.setPosition(o.getPosition().add(5, 0)) )就像你处理不变的东西一样。对于早期的虚拟机,这甚至可能是一个好主意,而对于现代的虚拟机,这很可能不是一个好主意。

sleske 9 年前

Java的早期API只不过是时间的产物。不变性在几年后才成为一个流行的概念。你说不变是“显而易见的”。现在可能是这样,但那时不是。就像依赖注入现在“明显”一样,但不是10年前。

创建日历对象有时也很昂贵。

出于向后兼容性的原因,它们仍然是这样的。更不幸的是,一旦认识到错误,旧类就不会被弃用,并且会为将来的所有API创建新的日期/时间类。这在某种程度上是由于JDK8采用了类似于jodatime的API( java.time ,JSR 310)但实际上太晚了。

dz. 15 年前

时间本身不容易测量和处理。看看维基百科关于 time .然后,对时间本身有不同的理解:绝对的时间点(作为常量),在某个地方的时间点,时间范围,时间的分辨率……

我记得,当我第一次看到java.util.date(jdk 1.0?)我是 真的? 很高兴。我所知道的语言没有这样的特点。我没有考虑时间转换等问题。

我认为这是混乱的,因为如果你从一个理解水平(xmlGregoricalEnder vs.Date)和需求水平(纳秒,过去2030年)发展到更高的水平,所有的变化都会留下混乱,但保持旧的不变。java.util.date也不例外。只需看看I/O子系统或者从awt到swing的转换…

正因为如此,“我们有时应该按下重置按钮。”(谁说的,顺便问一下?)

Jeshurun 14 年前

你可能会发现下面的帖子很有趣。它首先解释了日历类如何进入Java API,并对日期类的起源给出了一些启发。

The Seven Habits of Highly Dysfunctional Design