问为什么在InputStream/OutputStream中实现了close()？

EN

只有我的两分钱。这个答案的目的是给出一些想法和吸引更多的答案，而不是试图听起来像决定性的，甚至提供信息。

为什么流抽象基类而不是接口？

• 可以定义一个严格的最小接口。
  • 通常这包括:读取、写入、查找、告知(返回当前文件位置)、获取长度、截断(缩小文件大小)、关闭。

• 但是，为了使流实现更方便地使用，需要在类上使用许多帮助方法。
  • 如果没有这些帮助方法，它将使编程语言变得不切实际，因为如果使用流作为标准库的基本特性，那么就太麻烦了。
  • 这些帮助方法利用了最小的接口。
  • 通常，可以为这些助手方法提供默认(标准)实现，这将完全满足大多数情况下的需求。
  • 因此，使用抽象基类来提供这些默认的助手方法实现，以提高标准库的可用性。

是close()方法对于流？

的操作的基础。

与你的观点相反，我认为不需要关闭的溪流是少数，而不是多数。

• 文件系统句柄
• 操作系统拥有的资源，如：
  • 插座
  • 管道
  • 操作系统托管共享内存(与JVM托管内存相反)

• 数据库连接

坦率地说，

• 似乎数组支持的流是唯一不需要显式关闭的流类型。

成本效益分析是否有利于将close()方法包含到流接口中？

看来是这样的。对于不需要显式关闭的流，要求它提供不做任何操作的微不足道的close()方法是无害的。

类似的观察可以在C#语言中找到，在那里通常可以看到亚型 IDisposable的接口。

会不会在流接口中包含close()方法会对需要它的实现造成极大的伤害？

是。如果不将其放在接口上，或者将其分配给第二个Closeable接口，则会造成非常大的危害。

在下面的第一个代码片段中，假设InputStream不包含close()方法。下面是代码的样子：

public void parseAndCloseStream(InputStream strm) throws IOException
{
    if (strm == null) { /* ... to avoid NPE inside finally */ }
    try
    {
        // read from stream
    }
    finally
    {
        if (strm instanceof Closeable)
        {
            Closeable c = (Closeable)strm;
            c.close();
        }
    }
}

换句话说，由于省略意味着“并非每个InputStream都是关闭的”，因此任何InputStream实例的任何使用者现在都有额外的责任来检查实例是否确实是可关闭的。

然后，try-with模式还需要更多的代码，因为您不能在那里使用InputStream，除非您可以将其转换为可关闭的代码。

是否违反了界面隔离原则？

不是的。

• 如果一个方法对于大多数实现来说是操作的基础，那么要求它是有意义的。
• 同样，如果一个方法与该接口中的其他方法(即包含它的常识)相结合，那么它并不是违反的。

具体而言，接口隔离原则不要求：

• 不需要最少的接口；即使保持接口小而简单也有好处。
• 不需要将接口的所有正交面分开，如果这样做会造成更多的伤害而不是好处(极大的不便)。