他のインターフェイスから継承する場合、インターフェイスは「空」と見なされますか？

空のインターフェースは、私が知る限り、一般的に悪い習慣と見なされます-特に属性のようなものが言語によってサポートされている場合。

ただし、他のインターフェイスから継承する場合、そのインターフェイスは「空」と見なされますか？

interface I1 { ... }
interface I2 { ... } //unrelated to I1

interface I3
    : I1, I2
{
    // empty body
}

実装があることは何もI3実装する必要がありますI1とI2、および継承があること、異なるクラスのオブジェクトI3、その後（下記参照）を交換可能に使用することができるが、それは右呼び出すことですI3 空の？もしそうなら、これをアーキテクチャ化するより良い方法は何でしょうか？

// with I3 interface
class A : I3 { ... }
class B : I3 { ... }

class Test {
    void foo() {
        I3 something = new A();
        something = new B();
        something.SomeI1Function();
        something.SomeI2Function();
    }
}

// without I3 interface
class A : I1, I2 { ... }
class B : I1, I2 { ... }

class Test {
    void foo() {
        I1 something = new A();
        something = new B();
        something.SomeI1Function();
        something.SomeI2Function(); // we can't do this without casting first
    }
}

I3を実装するものはすべてI1とI2を実装する必要があり、I3を継承するさまざまなクラスのオブジェクトは交換可能に使用できます（以下を参照）。もしそうなら、これをアーキテクチャ化するより良い方法は何でしょうか？

"バンドル" I1とI2into I3は、両方を実装したい場所に適した（？）ショートカット、またはある種の構文シュガーを提供します。

このアプローチの問題は、あなたが明示的に実装するから他の開発者を止めることはできないということですI1 と I2並んで、それは両方の方法を動作しません-しばらくは: I3相当である: I1, I2、: I1, I2と同等ではありません: I3。機能的に同一であってもI1、両方をサポートするクラスで、サポートI2として検出されませんI3。

これは、同じことを達成するための2つの方法を提供していることを意味します-「手動」と「甘い」（構文シュガーを使用）。そして、それはコードの一貫性に悪影響を及ぼす可能性があります。ここで同じことを達成するために2つの異なる方法を提供し、別の場所ですでに8つの可能な組み合わせになります:)

void foo() {
    I1 something = new A();
    something = new B();
    something.SomeI1Function();
    something.SomeI2Function(); // we can't do this without casting first
}

OK、できません。しかし、実際には良い兆候でしょうか？

異なる責任I1をI2含意する場合（そもそもそれらを分離する必要はない）、2つの異なる責任を一度に実行foo()しようとするのは間違っているかもしれませんsomething。

言い換えれば、それfoo()自体が単一責任の原則に違反している可能性があり、それをキャストするためにキャストとランタイムタイプのチェックが必要であるという事実は、それについて警告する赤い旗です。

編集：

あなたはそれを確実にすることを主張した場合foo実装することを何かを取るI1とI2、あなたは別のパラメータとして渡すことができます：

void foo(I1 i1, I2 i2) 

そして、それらは同じオブジェクトである可能性があります。

foo(something, something);

何がfoo、彼らは同じインスタンスしているか、いない場合は注意して！

しかし、それが気になる場合（例えば、ステートレスではないため）、またはこれが見苦しいと思われる場合は、代わりにジェネリックを使用できます：

void Foo<T>(T something) where T: I1, I2

現在、一般的な制約は、外部の世界を何も汚染しないで、望ましい効果を処理します。これは、コンパイル時のチェックに基づいた慣用的なC＃であり、全体的に適切であると感じています。

私はI3 : I2, I1、それをサポートしていない言語でユニオン型をエミュレートする努力といくらか見ています（C＃またはJavaはサポートしませんが、ユニオン型は関数型言語に存在します）。

言語で実際にサポートされていない構造をエミュレートしようとすることは、しばしば不格好です。同様に、C＃では、mixinsをエミュレートする場合、拡張メソッドとインターフェイスを使用できます。可能？はい。良いアイデア？よく分かりません。

クラスが両方のインターフェースを実装することで特に重要な場合、両方から継承する3番目のインターフェースを作成しても何も問題はありません。ただし、過剰なエンジニアリングのtrapに陥らないように注意します。クラスは、どちらか、または両方から継承できます。これらの3つのケースでプログラムに十分なクラスがない限り、両方のインターフェイスを作成するのは少し大変です。これら2つのインターフェイスが相互に関係がない場合は確かにそうではありません（IComparableAndSerializableインターフェイスはご遠慮ください）。

両方のインターフェイスを継承する抽象クラスも作成でき、その抽象クラスをI3の代わりに使用できることを思い出してください。すべきではないと言うのは間違っていると思いますが、少なくとも正当な理由があるべきです。

空のインターフェイスは一般的に悪い習慣と見なされます

同意しません。マーカーインターフェイスについてお読みください。

典型的なインターフェースは実装クラスがサポートしなければならない機能を（メソッド宣言の形式で）指定しますが、マーカーインターフェースはそうする必要はありません。このようなインターフェイスが存在するだけで、実装クラスの特定の動作を示します。