在我的项目中，我定义了一个接口来描述每个不同的数据库连接类必须具有的方法。这被称为IDatabaseConnectivityObject。我的每个类都实现了这个接口，以确保它们都包含相同的方法来运行查询、建立连接等。
考虑以下代码：
IDatabaseConnectivityObject adoDataBaseConnection = new DbProviderFactoryConnection();
DbProviderFactoryConnection adoDataBaseConnection = new DbProviderFactoryConnection();
上述行的行为是否相同？如果是，为什么？如果没有，那为什么不呢？两者有什么好处？
这可能是一个非常愚蠢的问题，但我没有使用接口那么久，我不确定第 1 行是做什么的。我的理解是你不能创建一个接口的实例，因为它只是定义了行为，那么这条线怎么可能呢？
上述行的行为是否相同？如果是，为什么？
在运行时是的。不同之处在于，如果您声明类型变量，IDatabaseConnectivityObject那么在编译时您将只能在变量上看到此接口的成员。另一方面，如果您将其声明为，DbProviderFactoryConnection那么您将看到该类的所有成员。
作为一种好的做法，建议在声明变量（在这种情况下）时始终使用层次结构中可能的最高类型，IDatabaseConnectivityObject这允许您访问消费者需要的所有成员。
第一个将允许您交换IDatabaseConnectivityObject前进的不同实现。
这是一个很好的做法，因为它可以让您的系统更能抵抗向前发生的变化。保持较低的变革成本是关键。
接口定义了消费者可以依赖的合约，如果你愿意，也可以定义 API。如果您打算使用界面上存在的成员，则这两行在功能上是相同的。
使用接口只是表示你不在乎某些东西是如何实现的，只是为了契约而实现它。接口也促进了松散耦合。
针对接口进行编程的好处是，您是针对“协议”而不是“执行”或合同而不是实现进行编程。这对测试有很大的积极影响，因为您可以在测试期间模拟或存根接口以减少测试场景中无关依赖项的数量。
与上述类似的好处是，使用接口以及工厂模式、IoC 或 DI 之类的东西，您可以动态提供接口的不同实现——例如，为不同的客户提供不同的业务逻辑处理程序。
另一个好处是它有助于解决缺乏多重继承的问题。大多数东西都可以通过接口很好地表达，类可以实现多个接口。
你已经要求福利了。
当您针对接口进行编程（并使用工厂创建具体类型）时，这使得单元测试更容易，因为您可以模拟放入逻辑（单元）的实例。
这实际上是一个“设计模式原则”：
“编程到‘接口’，而不是‘实现’。” （四人帮 1995:18）