如果某个接口继承自其他接口，是否将其视为“空”？

据我所知，空接口通常被认为是不好的做法-特别是在语言支持的属性之类的地方。

但是，如果某个接口继承自其他接口，是否将其视为“空”？

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的不同类的对象（请参见下文），因此将I3称为空是正确的吗？如果是这样，哪种更好的架构方法呢？

“捆绑” I1，并I2为I3提供了一个很好（？）的快捷方式，或某种语法糖用于无论你想既来实现。

这种方法的问题是，你不能明确地执行停止其他开发商I1 和 I2并排，但它不工作两者兼得-而: I3相当的: I1, I2，: I1, I2是不是等同: I3。即使它们在功能上相同，但同时支持这两种I1并且I2不会被检测为support的类I3。

这意味着您提供两种完成同一件事的方式-“手动”和“甜”（使用语法糖）。这可能会对代码一致性产生严重影响。提供两种不同的方式可以在这里，那里和另一个地方完成同一件事，这已经导致8种可能的组合：)

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

好的，你不能。但这也许实际上是一个好兆头？

如果I1并且I2暗示着不同的责任（否则就没有必要首先将它们分开），那么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，则可以使用扩展方法和接口。可能？是。好主意？我不确定。

如果让一个类实现两个接口特别重要，那么创建第三个接口并从两个接口继承都没有错。但是，我要小心不要陷入过度设计的陷阱。一个类可以从一个或另一个继承。除非我的程序在这三种情况下都有大量的类，否则为这两种情况创建一个接口要花点功夫，并且如果这两个接口彼此之间没有关系（当然也请没有IComparableAndSerializable接口），那肯定不是一件容易的事。

我提醒您，您也可以创建一个从两个接口继承的抽象类，并且可以使用该抽象类代替I3。我认为说您不应该这样做是错误的，但是至少应该有充分的理由。

空接口通常被认为是不好的做法

我不同意。阅读有关标记接口的信息。

典型的接口指定实现类必须支持的功能（以方法声明的形式），而标记器接口则不必这样做。这种接口的存在表明在实现类方面的特定行为。