Why InputStream Design Is Wrong

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

这不仅仅关乎InputSteam,这个类是一个糟糕设计的很好的例子。我指的是三个重载的方法read()。我在Elegant Objects的第2.9节中提到了这个问题。简言之,我坚信接口应该是“功能贫乏的”。InputStream本应该是一个接口,并且应该只有一个read(byte[])方法。然后,如果它的作者想要给我们额外的功能,他们应该创建辅助的“智能”类。

现在的情况是这样的:

怎么了?拥有读取单个字节、字节数组甚至是字节数组并直接定位到缓冲区特定位置的能力非常方便!

然而,我们仍然缺少一些方法:读取字节并立即保存到文件中,转换为具有所选编码的文本,通过电子邮件发送和在Twitter上发布。如果在可怜的InputStream中也有这些功能就太好了。我希望Oracle Java团队正在着手解决这些问题。

与此同时,让我们看看这些聪明的工程师们为我们设计的东西到底有什么问题。或者也许让我展示一下我会如何设计InputStream,然后我们来对比一下:

这是我的设计。 InputStream 负责从流中读取字节。这个功能只有一个单一的方法。对每个人来说都方便吗?它能读取并在 Twitter 上发布吗?还不行。我们需要那个功能吗?当然需要,但这并不意味着我们会将其添加到接口中。相反,我们将创建辅助的“智能”类:

现在,我们想要从流中读取一个字节。下面是方法:

读取单个字节的功能不在InputStream之内,因为这不是它的职责。流在读取后无需知道如何处理数据。流只负责读取,而不是解析或后续操作。

接口必须保持简洁。

显然,在接口中进行方法重载是代码异味。拥有超过三个方法的接口是重构的良好候选对象。如果方法之间存在重载,那将是严重的问题。

接口必须保持简洁!

你可能会说InputStream的创建者关注性能,这就是为什么允许我们以三种不同的方式实现read()方法。那么我不得不再次问,为什么不创建一个用于读取并立即发布到Twitter上的方法呢?那将非常快速。这不就是我们所有人想要的吗?一个快速的软件,没有人有兴趣阅读或维护。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 22:22

sixnines availability badge   GitHub stars