我理解接口是一种抽象类型，它不包含任何数据，但是公开行为和属性，并且对象的实例是存在于内存中的对象的出现或副本。
我想知道编译器/底层代码如何处理这两者的差异？基于对此的回答，如果我将接口作为依赖项传递给对象而不是具体实例，为什么代码更松散耦合？如果我将接口中定义的DoSomething方法调用MyClass而不是DoSomething的具体实例中定义的MyClass方法，会发生什么区别？
答案 0 :(得分：1)
我知道你说你明白界面是什么 - 但我确实想知道这是否完全正确，因为你将第二个问题与第一个问题联系起来。第二个可以在不知道第一个的情况下回答，也不会受到任何影响。
特别关于为什么它更松散耦合的问题与编译器的实现或任何事情无关：它只是软件架构。
除了方法/属性的存在之外，接口对实现类型没有任何限制（从技术上讲，它们也是方法）。
实现甚至不必在类型本身上公开，类型也不必具有某个构造函数等。更重要的是 - 它甚至不必是类 。然后是（相当边缘情况）的事情，对于单个类型的接口可以具有相同接口的多个实现。
一旦使用基类，可能会引入一大堆其他限制。
没错，这些显然也是一件好事 - 例如，如果已知的具体基础是不可变的（为了一致性）并且在其构造函数中不允许'nulls'（所有这些都不能通过接口强制执行） ）。
答案 1 :(得分：0)
您可以拥有许多接口或抽象类的实现（具体实例）。
通常，您应该定义接受具有接口的类层次结构而不是具体类的方法，这样它们将是通用的，不必为您定义的每个新实现重写。
在基类或派生类中调用方法应该调用相同的方法，假设您正确覆盖了该方法。
答案 2 :(得分：0)
请查看MSDN杂志文章："Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects"了解实施细节 我认为运行时需要支持接口的主要原因尤其与具有不同编译时间的程序集可能在运行时相互连接的事实有关。