2009-07-22 5 views
1

Hmmm。私は、バイトを受け入れるクラスを記述しようとしており、この目的のためによく知られたインターフェースを実装したいと考えています。インターフェイスはAppendableまたはOutputStreamのようなものを探します

java.io.OutputStreamは抽象クラスであり、インターフェイスではありません(なぜ???)、その結果が何を延長するのか分かりませんので、私は緊張します。結果がなければ、それはインターフェースであったはずです。それ以外の場合は、equals()hashCode()のいずれか、またはSerializable関連の動作のいずれかを定義していると思うし、それを拡張しようとする前に知っておくべきことがあります。とにかく、私がそれを拡張すると、私は1つのスーパークラスを使い果たしたことになり、私のアプリケーションにとってより重要な何かを拡張することはできません。

java.lang.Appendableは、私が望むものを実行するインターフェイスですが、バイトではなく文字のためのインターフェイスです。

java.nio.WritableByteChannelは私が望むものであり、使用するかもしれませんが、バイト[]配列ではなく、入力としてByteBuffersを受け入れます。

その他のアドバイスやアドバイスはありますか? (p.s.はI/O質問のための最良のタグである「入出力」です)

+0

私は 'OutputStream'を拡張することについて何故緊張しているのか分かりません。あなたは詳しく説明できますか? (私はセラピストのように感じます!) –

+0

私は同意します。 OutputStreamではそれほど多くはありません。あなたは大丈夫です;] – pablochan

+0

:-)上記を参照してください。 –

答えて

1

java.io.DataOutputあなたが求めているよりも多くの方法がありますが、あなたはうまくいくかもしれません。

+0

ありがとう! –

1

なぜよく知られているインターフェイスを使用しますか?

目的に合わせて独自のインターフェイスを作成することには問題ありません。

さらに、私はAppendableまたはWritableByteChannelを「よく知られている」と呼んでいません。

+2

なぜですか?標準インタフェースを使用すると、アプリケーションコンポーネント間の結合を減らすことができるためです。 – skaffman

+0

標準インターフェースは、どのようにして複数のカップリングを減らすことができますか? – jjnguy

+1

標準インタフェースがすでに両方のコンポーネントに存在する可能性があるため、両者の間にコンパイル時の依存関係は必要ありません。 – skaffman

1

java.io.OutputStreamの拡張に問題はありません。基本クラスとして使用するように設計されています。心配な方は、OutputStreamのソースコードを見てください。

私の唯一の質問は、OutputStream APIがアプリケーションの要件と一致するか、別のAPIが適しているかどうかです。あなたのアプリケーションの要件に一層緊密に対応した独自のインターフェイスを設計するなら、誰も苦情を言うことはありません。

関連する問題