Çoklu arayüzleri birleştirmek için boş arayüz

İki arayüzünüz olduğunu varsayalım:

interface Readable {
    public void read();
}

interface Writable {
    public void write();
}

Bazı durumlarda, uygulama nesneleri bunlardan sadece birini destekleyebilir, ancak çoğu durumda uygulamalar her iki arabirimi de destekler. Arayüzleri kullanan insanlar şöyle bir şey yapmak zorunda kalacaklar:

// 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();

Bu seçeneklerin hiçbiri son derece kullanışlı değildir, hatta bunu bir yöntem parametresi olarak istediğinizi düşünürken daha da fazladır.

Bir çözüm bir sarma arabirimi bildirmek olacaktır:

interface TheWholeShabam extends Readable, Writable {}

Okunabilir ve Yazılabilir hem destekleyen tüm uygulamaları: Ama bu belirli bir sorunu var olması onlar arabirimini kullanan kişilerle uyumlu olmasını istiyorsanız TheWholeShabam uygulamaktır. Her iki arayüzün garantili varlığından başka bir şey sunmasa da.

Bu sorunun temiz bir çözümü var mı yoksa sarıcı arabirimi için gitmeli miyim?

GÜNCELLEME

Aslında hem okunabilir hem de yazılabilir bir nesneye sahip olmak genellikle gereklidir, bu nedenle argümanlardaki endişeleri ayırmak her zaman temiz bir çözüm değildir.

Update2

(yorum olarak daha kolay cevap olarak çıkarılır)

Update3

Lütfen bunun için birincil kullanıcı tabanının akış olmadığına dikkat edin (bunlar da desteklenmelidir). Akarsu, girdi ve çıktı arasında çok belirgin bir ayrım yapar ve sorumlulukların arasında net bir ayrım vardır. Bunun yerine, yazabileceğiniz ve okuyabileceğiniz bir nesneye, kendisine çok özel bir duruma sahip bir nesneye ihtiyaç duyduğunuz bir bytebuffer gibi bir şey düşünün. Bu nesneler vardır, çünkü asenkron I / O, kodlamalar, ...

Update4

Denediğim ilk şeylerden biri, aşağıda verilen öneriyle aynıydı (kabul edilen cevabı kontrol edin), ancak çok kırılgan olduğu kanıtlandı.

Diyelim ki türü döndürmesi gereken bir sınıfınız var:

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

Bu yöntemi çağırırsanız, genel RW nesneyi alan değişken tarafından belirlenir, bu nedenle bu var.

MyObject myObject = someInstance.getItAll();

Bu işe yarayacaktır, ancak bir kez daha bir uygulamaya bağlar ve aslında çalışma zamanında sınıf ifadeleri atabilir (döndürülene bağlı olarak).

Buna ek olarak, RW türünde bir sınıf değişkeni istiyorsanız, sınıf düzeyinde genel tanımlamanız gerekir.

Evet, hem uzanan bir underspecified türü olarak yöntem parametresini ilan edebilir Readableve Writable:

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

Yöntem bildirimi korkunç görünüyor, ancak bunu kullanmak, birleştirilmiş arayüz hakkında bilgi sahibi olmaktan daha kolaydır.

myObjectHem a olarak hem de ihtiyacınız olan bir yer varsa Readableve Writableşunları yapabilirsiniz:

• O yeri refactor mu? Okuma ve yazma iki farklı şeydir. Bir yöntem her ikisini birden yaparsa, belki de tek sorumluluk ilkesine uymaz.

• Geçiş myObjectbir şekilde iki kez Readableve bir şekilde Writable(iki argüman). Yöntem, aynı nesne olup olmamasına ne dikkat ediyor?

Şu anda cevapların hiçbiri, okunabilir veya yazılabilir değil, her ikisi de gerekmediği durumla ilgili değildir . A'ya yazarken, bu verileri A'dan geri okuyabileceğinizi, A'ya yazıp B'den okuyamayacağınızı ve sadece aynı nesne olduklarını umabileceğinizi garanti etmeniz gerekir. Usecases bol, örneğin bir ByteBuffer kullanmak her yerde.

Neyse, üzerinde çalıştığım modülü neredeyse bitirdim ve şu anda sarmalayıcı arayüzünü seçtim:

interface Container extends Readable, Writable {}

Şimdi en azından şunları yapabilirsiniz:

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

Kendi kapsayıcı uygulamalarım (şu anda 3) ayrı kapsayıcıların aksine kapsayıcıyı uyguluyor ancak birisi bunu bir uygulamada unutursa, IOUtils bir yardımcı yöntem sağlar:

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

Bunun en uygun çözüm olmadığını biliyorum, ancak şu anda hala en iyi çıkış yolu çünkü Container hala oldukça büyük bir kullanım alanı.

Genel bir MyObject örneği verildiğinde, bunun her zaman okumaları mı yoksa yazmaları mı desteklediğini bilmeniz gerekir. Yani şöyle bir kodunuz olur:

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

Basit bir durumda, bunu geliştirebileceğinizi sanmıyorum. Ancak Okunabilir'i okuduktan sonra başka bir dosyaya yazmakreadThisReadable isterse , garipleşir.

Bu yüzden muhtemelen bununla giderdim:

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

Bunu bir parametre olarak almak readThisReadable, şimdi readThisWholeShabam, sadece MyObject'i değil, TheWholeShabam'ı uygulayan herhangi bir sınıfı işleyebilir. Ve buna yazılabilir ise bunu yazmak ve Değilse yazamam. (Gerçek "Çok Biçimliliğimiz" var.)

Böylece ilk kod kümesi şöyle olur:

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

Ve readThisWholeShebam () okunabilirlik kontrolünü yaparak bir satırı buraya kaydedebilirsiniz.

Bu, yalnızca Okunabilir olanın sadece isWriteable () ( false döndüren ) ve write () (hiçbir şey yapmadan) uygulaması gerektiği anlamına gelir , ancak şimdi daha önce gidemediği her türlü yere ve TheWholeShabam'ı işleyen tüm kodlara gidebilir nesneler bizim tarafımızdan daha fazla çaba sarf etmeden onunla ilgilenecektir.

Başka bir şey: okumayan bir sınıfta read () çağrısını ve bir şeyi çöpe atmadan yazmayan bir sınıfta write () çağrısı yapabiliyorsanız, isReadable () ve isWriteable öğelerini atlayabilirsiniz. () yöntemleri. Eğer işe yararsa, bu en şık yol olacaktır.