0

FilterInputStreamやFilterOutputStreamのようなクラスを書いています。

のように見える

public FilterReadableByteChannel implements ReadableByteChannel {

    // Should I permit null for channel?
    public FilterReadableByteChannel(final ReadableByteChannel channel) {
       // ...
    }
}

そして、FilterInputStreamとFilterOutputStreamの両方がソースを許可することがわかりましたnull。

 * @param   in   the underlying input stream, or <code>null</code> if
 *          this instance is to be created without an underlying stream.

質問：

  1. これには実際的な理由がありますか？
  2. 作成後に基になるソースを変更する可能性はありますか?

それが答えになる可能性があることは知っていWhy Not?ますが、元の API 設計者がこれを行った理由があるかどうかを知りたいです。

4

1 に答える 1

2

これには実際的な理由がありますか？

はい。そのように宣言されていなくても、クラスFilter*Streamは概念的に抽象クラスです。IOW、それらは拡張するためにのみ存在します。サブクラスは、構築後にinoroutパラメーターを提供する必要がある場合があり (例: 遅延; 最初の実際の使用時)、Filter*Streamこの柔軟性を提供します。

作成後に基になるソースを変更する可能性はありますか?

明らかなケースは、 source が initial の場合ですnull。私の頭に浮かぶ他のケースは次のとおりです。 1.Filter*Streamセレクターとして機能するサブクラスを作成します。IOW には、あるストリームから別のストリームに切り替えるためのいくつかの基本的なストリームとメソッドがあります。FilterInputStream2.異なる を連結する のサブクラスを作成しInputStreamます。3.FilterOutputStream出力を異なる に分割する のサブクラスを作成しますOutputStream。

なぜいけないのですか？答えになる可能性がありますが、元の API 設計者がこれを行った理由があるかどうかを知りたいです。

はい: 一般性。

于 2013-08-27T06:05:28.040 に答える