传递接口而不是对象实例
以SqlBulkCopy.WriteToServer（）方法为例。 其中一个重载采用IDataReader作为参数。 我的问题是，将接口传递给方法而不是对象实例本身有什么好处/好处？
http://msdn.microsoft.com/en-us/library/434atets.aspx
您可以为该一个接口提供许多可能的实现。 它更好地依赖于抽象（在这种情况下是接口）而不是实际的具体类 – 这允许更好的灵活性和可测试性。
这也将焦点放在WriteToServer()方法真正需要的内容上 – 它的契约唯一需要的是调用者传递给具有IDataReader接口声明的方法/属性的具体类的任何实例。
传递接口意味着您可以传递实现该接口的任何对象而不仅仅是一个特定对象。
这使得代码更加灵活，因为它不必知道现在或将来可能实现接口的所有可能对象。
它还使其更加健壮，因为它只需要处理众所周知和定义的接口上的属性和方法。
forms参数类型是接口类型 – 这意味着您可以传入实现此接口的任何对象（或者更确切地说，是实现接口的对象的实例）。
您没有传入接口，而是传入符合接口定义的协定的对象 。
因此，如果您的数据源是SQL Server，那么您将传递一个SqlDataReader ，如果Oracle是一个OracleDataReader 。
您还可以实现自己的数据读取器并将其传递给函数，甚至可以编写模拟数据读取器来彻底测试该方法。
这是一个众所周知的设计原则 – 程序到接口，而不是实现 。
从MSDN – 何时使用接口 ：
接口是一种function强大的编程工具，因为它们允许您将对象的定义与其实现分开。
当一个方法将其中一个参数列为接口时，它不会要求您传入该接口的实例（这无论如何都是不可能的，您可以创建接口实例），它要求您传入任何实现的对象那个界面。
例：
interface IMyObject { public void SomeMethod(); } public class MyObject : IMyObject { public void SomeMethod() { // implementing code here } }
您现在可以将任何MyObject实例作为IMyObject类型的参数传递:)
public class YourObject { public void DoSomething(IMyObject o) { // some code here } } YourObject yo = new YourObject(); MyObject mo = new MyObject(); yo.DoSomething(mo); // works
我希望这是有道理的！
实际上，它希望您传递实现接口的类型的实例，而不是接口本身。
当方法唯一关心的是接口声明的方法时，使用接口类型。 只要对象实现了该接口，就可以在该对象上调用其中定义的方法。
这是接口的原因之一 – 在这个例子中，接口的所有使用者（即函数）关心的是它可以读取数据 – 它不介意它是来自SqlDataReader还是OleDataReader或任何其他提供者 – 替代方案将提供单独的重载，对于每个可能的数据读取器实际上是相同的（这当然是不切实际的，因为有人可能会提出一个，例如dBase或更奇特的数据库引擎）