5

ブロックの引用は Java Docs からのものです -

FilterInputStream には、データの基本的なソースとして使用する他の入力ストリームが含まれており、途中でデータを変換したり、追加機能を提供したりする可能性があります。

DataInputStream を使用すると、アプリケーションは、基礎となる入力ストリームからプリミティブな Java データ型をマシンに依存しない方法で読み取ることができます。

したがってDataInputStream、FilterInputStream

ObjectInputStream は、ObjectOutputStream を使用して以前に書き込まれたプリミティブ データとオブジェクトを逆シリアル化します。

ただし、何らかの理由で、基になる入力ストリームからオブジェクト (今回はプリミティブ型ではない) も読み取っていますが、ObjectInputStream拡張されません。FilterInputStream関連するクラスの分岐は次のとおりです。

代替テキスト

同じことの設計上の理由はありますか？

4

3 に答える 3

3

賢明な質問。考えてみれば、Object*Stream拡張するように設計されていた可能性があると思いますFilter*Stream(出力または入力も同様です)。なぜそうしなかったのでしょうか？おそらく理由：

  1. それは本当の利益をもたらしません。Maciej が説明したように、 のポイントはFilter*Stream、クラスのいくつかの重要でない編成は別として、そのパターンを持つクラスの共通のデフォルトの (そしてかなり些細な)実装を提供することです (いくつかの基になるストリームから読み書きし、最終的にストリームを変換します)。 、他のクラス (Java API またはユーザーから) によって拡張されます。しかし、それはインターフェイスFilter*Streamに関するものではありません。たとえば、 as 引数を必要とするメソッドを見つけたり実装したりすることはほとんどありません。したがって、クラスにorを継承させる決定は、代替手段がある場合、ほとんどが実装上の決定です。クラスのユーザーは基本的に気にしません。Filter*Stream*StreamFilter*Stream

  2. の設計者は、追加の空のコンストラクター (基になる を持たない)ObjectOutputStreamを提供することにより、クラスを拡張し、完全に再実装することをいとわない人に、さらなる柔軟性を与えることにしました。この機能（かなりまれだと思います）により、クラスは（概念的にも実装的にも）クラスから少し離れています。繰り返しますが、これは決定的なものではないようです。OuputStreamFilter*Stream

于 2010-05-24T13:17:31.987 に答える
2

次の違いがあります。

  • 論理継承 (インターフェースを共有)
  • クラス間でコードを共有する場合の「コード」継承

抽象的でLinkedListはないので、論理的ではありません。AbstractListただし、コードの観点からは、Listメソッドのいくつかの実装を共有することは有益です。なぜなら、それらは通常同じ効率で他の観点から実装できるからです (たとえば、isEmptyとして実装できますsize() == 0)。

GObject などの一部のプラットフォーム (または Haskell を拡張したものもありますが、OO 言語ではなく、多くの点でまったく異なります) では、それを定義するインターフェイスでメソッドのデフォルトの実装が許可されています。

ただし、Abstract*クラスを使用してコードを再利用する Java には当てはまりません。Filter*Stream出力がどこかに送信されることをあまり定義していません (Java I/O の全体的なポイントは、プロデューサー/レシーバーが気にしないことです) が、共通コードを再利用するために使用されます。

于 2010-05-24T12:53:45.770 に答える
1

ObjectInputStream は FilterInputStream のすべてのメソッドをオーバーライドする必要があったと思います。

これを行うと、その関係を維持する意味がありません。

重要なこと: ObjectInputStreamはInputStream (他のメソッドに加えてプリミティブ データを書き込むことができます) であり、その関係はそこにあります。

于 2010-05-24T12:43:31.880 に答える