C#接口是一个让很多初学C#者容易迷糊的东西，用起来好像很简单，定义接口，里面包含方法，但没有方法具体实现的代码，然后在继承该接口的类里面要实现接口的所有方法的代码，但没有真正认识到接口的作用的时候就觉得用接口是多此一举，当然你这样想那是绝对绝对错误的。
我们定义一个接口：
public interface IBark
{
void Bark();
}
再定义一个类，继承于IBark，并且必需实现其中的Bark()方法：
public class Dog: IBark
{
public Dog()
{}
public void Bark()
{
Consol.write("汪汪");
}
}
然后，声明Dog的一个实例，并调用Bark()方法
Dog 旺财=new Dog();
旺财.Bark();
试想一样，若是想调用Bark()方法，只需要在Dog()中声明这样的一个方法不就行了吗，干什么还要用接口呢？因为接口中并没有Bark()具体实现，真的实现还是要在Dog()中，那么使用接口不是多此一举吗?
有人是这样解释的：从接口的定义方面来说，接口其实就是类和类之间的一种协定，一种约束。还拿上面的例子来说，所有继承了IBark接口的类中必需实现Bark()方法。那么从用户(使用类的用户)的角度来说，如果他知道了某个类是继承于IBark接口，那么他就可以放心大胆的调用Bark()方法，而不用管Bark()方法具体是如何实现的。
比如，我们另外写了一个类Cat：
public class Cat: IBark
{
public Cat()
{}
public void Bark()
{
Consol.write("喵喵");
}
}
当用户用到Cat类或是Dog类的时候，知道他们继承于IBark，那么不用管类里的具体实现，而就可以直接调用Bark()方法，因为这两个类中肯定有关于Bark()方法的具体实现。
如果我们从设计的角度来看，一个项目中用若干个类需要去编写，由于这些类比较复杂，工作量比较大，这样每个类就需要占用一个工作人员进行编写。比如A程序员去定Dog类，B程序员去写Cat类。这两个类本来没什么联系的，可是由于用户需要他们都实现一个关于"叫"的方法。这就要对他们进行一种约束。让他们都继承于IBark接口，目的是方便统一管理。
另一个是方便调用。当然了，不使用接口一样可以达到目的。只不过这样的话，这种约束就不那么明显，如果这样类还有Duck类等等，比较多的时候难免有人会漏掉这样方法。所以说还是通过接口更可靠一些，约束力更强一些。
from:
http://www.cnblogs.com/panjun-Donet/articles/1131393.html
http://www.189works.com/article-43241-1.html
http://www.cnblogs.com/zhchongyao/archive/2010/02/24/1672732.html