Java API设计不当，为什么？

Question

我听过很多，Java API的设计很糟糕。你同意吗，如果是的话，怎么样？我知道日历/日期api存在重大问题。集合api需要使用大量的样板代码。对于某些事情，File / IO API可能很复杂。

但是，这适用于整个船上吗？以及哪些版本的Java？

Answer 1

简而言之，Java API没问题。

更长的答案是，有些API经历了Java版本的更改，有时甚至是重要的，可能包含奇怪的部分。例如，日期有很多不赞成使用的方法。然而，重要的是那些API 确实存在。 Java非常强大，它的标准库可以为几乎任何东西找到API（可能并不总是完美的API，但足够好）。

P.S。下次有人发表这样的陈述时，问他在自己的生活中用自己设计了多少种语言。

Answer 2

Java并不是一个设计糟糕的API。 Java是在当前最佳实践尚未确切知晓的时候制作的。很多实现都以一种现在不受欢迎的方式完成。从那时起，为了纳入更好的技术和实践，已经做了大量的工作。这就是为什么有很多不推荐使用的代码。

在惊人的书Effective Java中谈到了一堆这样的东西。 Bloch谈到了在初始实施中所犯的一些“错误”，以及他们如何努力解决这些问题。如果您是一位认真的Java开发人员并且没有检查过Effective Java，我会高度推荐它。 （我实际上推荐Bloch's books.中的所有3个。他是一位对Java有透彻理解的优秀作家。）

Answer 3

你可能会说它“设计得很差”，因为如果他们现在必须这样做，它的作者会以不同的方式构建它。然而，他们多年来一直在努力做到最好。然而，后见之明是20/20。

Java API与任何必须“在运行时发展”的库存在同样的问题。

自Java首次出现以来已经有很多年了，关于语言和库的许多设计决策都在不断发展。但是，向后兼容的需要会限制API并对其进行更改。

可用性问题有很多具体的例子（过去几年我一直在研究它们），但很久以来，很少有API是完美的。

Answer 4

书中Effective Java涵盖了“Java API不好”的部分内容。

API的某些部分，比如java.util.Date，设计很差（从JDK 1.1开始，几乎所有方法都被弃用）。

还有一些其他的东西，例如某些JDK 1.0类缺少接口（之所以发生这种情况是因为创建时没有接口这样的东西（接口是在1.0之前添加但在0.0之后添加）。 p>

有些事情没有“正确”完成，因为JDK 1.1在AWT更改中由于JavaBeans和使用的命名约定而有很多变化之后出现了这个惯例。

在语言更改之前还有一些其他事情是不可能的，例如枚举和泛型。

很多API都很好。有些是穷人。 JDK 1.0中的早期内容显然是为HotJava（一个全Java Web浏览器）编写的，并没有真正考虑过一般消费。

可以肯定地说，API越旧越“贫穷”。较新的API是根据之前的知识设计的。这也是langauges - Java（取决于你的意见）比C ++更好。 C ++（取决于你的意见）比C等更好。

Answer 5

Java已经过时了（它起源于90年代早期，虽然它直到1995年左右才发布到1.0）并且任何旧的API都可以批评。并不是说它们本身就不好。他们只是他们时代的产物，现在认为哲学很糟糕（通常有充分理由，但并非总是如此）。

解决你提出的问题：

• 日期很糟糕，因为它是可变的。一个不可变的日期类会更清晰（Calendar有同样的问题）;
• String上的公共构造函数充其量是有问题的。关于这是否是一个问题，存在一些分歧。在我看来，这不过是一个大问题;
• java.io. *类让我想起了一些C ++ iostream库，因为它们是我认为历史证明不成功的实验（如果不是失败的话）。只需查看必须编写的代码即可将文本文件读入String。大多数其他语言都有一个标准的电话，它会这样做。

还有其他人：

• 1.2之前的收藏品存在问题。 Josh Bloch（Effective Java成名）是1.2中Java Collections框架更改的架构师。对于所有类，抽象实现等的良好和包含接口，这是一个巨大的变化;
• java.util.Properties扩展了Hashtable。这是当时产品的典型例子。在90年代，对象框架倾向于从某些东西继承。如今，这种倾向是（正确地）构成而非继承，但10 - 15年前并非如此。

Answer 6

我不会说它的设计都很糟糕。主要问题是向后兼容性，人们仍然期望长期被弃用的功能可用，因此10年前编写的代码不必更改。这使得API相当大，并且通常允许多种方式执行相同的操作，而不清楚哪一个更好。

Answer 7

  

Java API设计不当，为什么？

没有

因为虽然它并不完美，但是不好的API的数量如果比那个非常棒的部分少得多！

无论如何，你真的应该问这个，你直接听到了谁，否则它将在我的国家被称为“破碎的电话”（否则是一个伟大的孩子游戏:)）链中的每个节点按摩修改了消息的细微之处，最后修改了如下内容：

我不喜欢java.util.Calendar

最终可能

Java API完全破坏，应该将设计器入狱。

当然中间有一个“消息转换”!!!

:)

Answer 8

像任何有一段时间的东西一样，它变得陈旧。与.NET一样，Sun等人也试图保持新的东西。但是，时间停滞在一切，特别是考虑到你不能改变界面，只是添加，因为改变打破了事情。 ： - ）

Answer 9

不， Java API对于大多数部件来说都很棒，但它的某些部分却很糟糕。每个人都使用日期和日历作为示例（这里是强制性的joda-time链接）但我使用XML API（原生/ W3C，因为现在有几个）也是一个很好的例子：整个API的那一部分的问题在于它不能按预期工作，并且不符合API的其余部分。

Java API的另一个重要因素是它是一致的，不仅仅在其自身内部，而且在版本和平台（AWT除外）中，我确定没有使用Java的任何神奇之处API还没有在进行版本切换时改变/破坏了一些东西。

Answer 10

我在〜1995年开始使用Java API。任何旧的API都很容易被批评。

回答为什么：

的问题

• Java引入的枚举太迟了 - 如果从一开始就有枚举，那么API就会好得多。
• WORA（写一次，到处运行） - 或者像有人说“一次编写，随处调试”。当你的目标是最不常见的恶魔形成者时，制作出色的API是非常困难的。没有“真正的”Windows或Mac或Unix或Linux开发人员可以对Java感到满意。