複数のインターフェイスを結合する空のインターフェイス

次の2つのインターフェイスがあるとします。

interface Readable {
    public void read();
}

interface Writable {
    public void write();
}

場合によっては、実装オブジェクトはこれらの1つしかサポートできませんが、多くの場合、実装は両方のインターフェイスをサポートします。インターフェイスを使用する人々は次のようなことをしなければなりません：

// can't write to it without explicit casting
Readable myObject = new MyObject();

// can't read from it without explicit casting
Writable myObject = new MyObject();

// tight coupling to actual implementation
MyObject myObject = new MyObject();

これらのオプションはどれも非常に便利ではありません。これをメソッドパラメーターとして使用することを考えると、さらに便利です。

1つの解決策は、ラッピングインターフェイスを宣言することです。

interface TheWholeShabam extends Readable, Writable {}

リード・ライト可能の両方がサポートするすべての実装：しかし、これはある特定の問題がある持っている、彼らはインターフェイスを使用している人々との互換性を持つようにしたい場合はTheWholeShabamを実装することを。たとえ両方のインターフェースの存在が保証されていること以外は何も提供しませんが。

この問題に対する明確な解決策はありますか、それともラッパーインターフェイスを使用する必要がありますか？

更新

実際には、読み取りと書き込みの両方が可能なオブジェクトを用意する必要がある場合が多いので、単に引数の懸念を分離するだけでは必ずしもきれいな解決策とは限りません。

更新2

（回答として抽出されているため、コメントしやすくなっています）

更新3

これの主なユースケースはストリームではないことに注意してください（ただし、それらもサポートする必要があります）。ストリームは入力と出力を非常に明確に区別し、責任の明確な分離があります。むしろ、非常に特定の状態がアタッチされている1つのオブジェクトに書き込みと読み取りができる1つのオブジェクトが必要なバイトバッファのようなものを考えてください。これらのオブジェクトは、非同期I / O、エンコードなどのいくつかの場合に非常に役立つために存在します。

更新4

私が最初に試したものの1つは、以下に示す提案と同じでした（受け入れられた答えを確認してください）が、あまりにも壊れやすいことが判明しました。

型を返す必要があるクラスがあるとします：

public <RW extends Readable & Writable> RW getItAll();

このメソッドを呼び出す場合、ジェネリックRWはオブジェクトを受け取る変数によって決定されるため、この変数を記述する方法が必要です。

MyObject myObject = someInstance.getItAll();

これは機能しますが、もう一度実装に結び付け、実行時にクラスキャスト例外をスローする場合があります（返される内容によって異なります）。

さらに、RW型のクラス変数が必要な場合は、クラスレベルでジェネリックを定義する必要があります。

はい、メソッドパラメータを、Readableとの両方を拡張する指定不足の型として宣言できますWritable。

public <RW extends Readable & Writable> void process(RW thing);

メソッド宣言はひどいように見えますが、統一されたインターフェースについて知る必要があるよりも、それを使用する方が簡単です。

あなたが必要な場所場所がある場合はmyObject、両方のAとReadableし、Writable次のことができます。

• その場所をリファクタリングしますか？読み取りと書き込みは異なるものです。メソッドが両方を実行する場合、おそらく単一の責任原則に従っていません。

• myObjecta Readableおよびa Writable（2つの引数）として2回渡します。メソッドは、それが同じオブジェクトであるかどうかを何に気にしますか？

現在、読み取りまたは書き込みが必要ではなく、両方が必要な状況に対処する回答はありません。Aに書き込むとき、Aに書き込むのではなく、Aからデータを読み取ることができ、Bから読み取ることができ、実際には同じオブジェクトであることを保証する必要があります。ユースケースは豊富です。たとえば、ByteBufferを使用するすべての場所です。

とにかく、作業中のモジュールはほぼ完成しており、現在、ラッパーインターフェイスを選択しています。

interface Container extends Readable, Writable {}

これで、少なくとも次のことができます。

Container container = IOUtils.newContainer();
container.write("something".getBytes());
System.out.println(IOUtils.toString(container));

コンテナの現在の実装（現在3）はすべて、個別のインターフェイスではなくコンテナを実装していますが、実装でこれを忘れてしまった場合、IOUtilsはユーティリティメソッドを提供します。

Readable myReadable = ...;
// assuming myReadable is also Writable you can do this:
Container container = IOUtils.toByteContainer(myReadable);

私はこれが最適なソリューションではないことを知っていますが、コンテナはまだかなり大きなユースケースであるため、現時点ではまだ最善の方法です。

汎用のMyObjectインスタンスを指定すると、読み取りまたは書き込みをサポートするかどうかを常に知る必要があります。したがって、次のようなコードがあります。

if (myObject instanceof Readable)  {
    Readable  r = (Readable) myObject;
    readThisReadable( r );
}

単純な場合、これを改善できるとは思いません。しかし、Readableを読み込んだ後に別のファイルにReadable readThisReadableを書き込みたい場合は、扱いにくくなります。

だから私はおそらくこれで行くだろう：

interface TheWholeShabam  {
    public boolean  isReadable();
    public boolean  isWriteable();
    public void     read();
    public void     write();
}

これをパラメータとして使用するとreadThisReadable、readThisWholeShabamMyObjectだけでなく、TheWholeShabamを実装するクラスを処理できるようになりました。 そして、書き込み可能な場合は書き込むことができ、書き込み可能でない場合は書き込むことができません。（実際の「ポリモーフィズム」があります。）

したがって、最初のコードセットは次のようになります。

TheWholeShabam  myObject = ...;
if (myObject.isReadable()
    readThisWholeShebam( myObject );

また、readThisWholeShebam（）に可読性チェックを実行させることで、ここに行を保存できます。

これは、以前のReadable-onlyがisWriteable（）（falseを返す）とwrite（）（何もしない）を実装する必要があることを意味します。オブジェクトは、それ以上の努力をせずに対処します。

もう1つ：読み取りを行わないクラスでread（）の呼び出し、書き込みを行わないクラスでwrite（）の呼び出しを処理できる場合、isReadable（）およびisWriteableをスキップできます。 （）メソッド。これは、うまく機能する場合、これを処理する最もエレガントな方法です。