问题描述
我正在编写类似 FilterInputStream 或 FilterOutputStream.
I'm writing classes work like FilterInputStream or FilterOutputStream.
看起来像
public FilterReadableByteChannel implements ReadableByteChannel {
// Should I permit null for channel?
public FilterReadableByteChannel(final ReadableByteChannel channel) {
// ...
}
}
而且我发现 FilterInputStream和 FilterOutputStream 允许 null 源代码.
And I found that both FilterInputStream and FilterOutputStream permit null source.
* @param in the underlying input stream, or <code>null</code> if
* this instance is to be created without an underlying stream.
问题:
- 这有什么实际原因吗?
- 是否有可能在创建后更改底层源的情况?
我知道 Why Not? 可能是一个答案，但我想知道最初的 API 设计者是否有任何理由这样做.
I know that Why Not? could be an answer, but I want to know if there were any reason why the original API designer did this.
推荐答案
是的.即使没有这样声明，Filter*Stream 类在概念上也是抽象类.IOW，它们的存在只是为了扩展.子类可能需要在构造后提供 in 或 out 参数(例如:懒惰；第一次真正使用时)，并且 Filter*Stream 给它们这种灵活性.
Yes. Even if not declared as such, classes Filter*Stream are conceptually abstract classes. IOW, they only exist to be extended. Subclasses could need to provide the in or out parameters after construction (example: lazily; on first real use), and Filter*Stream gives them this flexibility.
是否有可能在创建后更改底层源的情况?
最明显的情况是 source 最初是 null.我想到的其他情况是:1. 创建一个作为选择器的 Filter*Stream 的子类.IOW，有几个底层流和方法可以从一个切换到另一个.2. 创建FilterInputStream 的子类，连接不同的InputStream.3. 创建FilterOutputStream 的子类，将输出拆分为不同的OutputStream.
The obvious case is when source is initially null. Other cases that come to my mind are: 1. Creating a subclass of Filter*Stream that acts as a selector. IOW, has several underlying streams and methods to switch from one to the other. 2. Creating a subclass of FilterInputStream that concatenates different InputStreams. 3. Creating a subclass of FilterOutputStream that splits output into different OutputStreams.
我知道为什么不呢?可能是一个答案，但我想知道最初的 API 设计者是否有任何理由这样做.
是:一般性.
这篇关于FilterInputStream/FilterOutputStream 的 null 源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！