接口存在的意义！？

[$扫地僧$]

那位大虾麻烦给我解释一下 C#编程的中的接口有什么意义啊！！
不过是些方法名的集合而已,自己一开始就写在自己想要实现的类里面不就可以了吗
还搞的怎么麻烦 又要去继承接口，再来实现方法
麻烦那位大虾说说 为什么要这么做啊！！！！

[睡神在睡觉]

感觉接口使用和类的封装还是要根据个人需求来说，毕竟多调用一层就要多一层的时间~在执行效率上还是会受影响的，合理使用比较好

[sunshine_anycall]

可以满足知识最少原则，比分层开发里的接口层

[lunat]

也可以有属性啊
据我所知 有以下好处
1.在处理多个具有某些相同特性或者行为的对象时，能够通过提升转换统一处理
2.多人合作开发的时候有一个共同的约定，以方便对象的交互
3.方便代码维护

[GTX280]

C#里类只能继承自一个类，而一个类可以继承多个接口。如果想让一个类具有多种行为，那么就让它继承多个接口，这在设计模式中非常重要。
楼主多看看C#中接口的用法吧

[HDNGO]

接口用于描述一组类的公共方法/公共属性. 它不实现任何的方法或属性，只是告诉继承它的类《至少》要实现哪些功能,继承它的类可以增加自己的方法.

使用接口可以使继承它的类: 命名统一/规范,易于维护.比如: 两个类 "狗"和"猫",如果它们都继承了接口"动物",其中动物里面有个方法Behavior(),那么狗和猫必须得实现Behavior()方法，并且都命名为Behavior这样就不会出现命名太杂乱的现象.如果命名不是Behavior()，接口会约束即不按接口约束命名编译不会通过.

提供永远的接口。当类增加时，现有接口方法能够满足继承类中的大多数方法，没必要重新给新类设计一组方法，也节省了代码，提高了开发效率.

[king19840811]

多态性
例
interface a
{
//
//
//
}
class A:a
{
}
class B:a
{
}
class c:a
{
}
class Test
{
static void Main()
{
public void Method1(a xxx)
{
//上面的方法可以接受任何实现了该结构的类型
}
}
}


假设我们公司有两种程序员：VB程序员，指的是用VB写程序的程序员，用clsVBProgramer这个类表示；Delphi程序员指的是用Delphi写程序的程序员，用clsDelphiProgramer这个类来表示。每个类都有一个WriteCode()方法。定义如下：
class clsVBProgramer()
{
....
WriteCode()
{
//用VB语言写代码；
}
....
}

class clsDelphiProgramer()
{
....
WriteCode()
{
//用Delphi语言写代码；
}
....
}

现在公司来了一个项目，要求派某个程序员写一个程序。
class clsProject()
{
....
WritePrograme(clsVBProgramer programer)//用VB写代码
{
programer.WriteCode();
}
WritePrograme(clsDelphiProgramer programer)//重载方法，用Delphi写代码
{
programer.WriteCode();
}
......
}
在主程序中我们可以这样写：
main()
{
clsProject proj=new clsProject;
//如果需要用VB写代码
clsVBProgramer programer1=new clsVBProgramer;
proj.WritePrograme(programer1);
//如果需要用Delphi写代码
clsDelphiProgramer programer2=new clsDelphiProgramer;
proj.WritePrograme(programer2);
}

但是如果这时公司又来了一个C#程序员，我们怎么改这段程序，使它能够实现用C#写程序的功能呢？我们需要增加一个新类clsCSharpProgramer,同时在此clsProject这个类中要再次重载WritePrograme（clsCSharpProgramer programer）方法。这下麻烦多了。如果还有C程序员，C++程序员，JAVA程序员呢。麻烦大了！

但是如果改用接口，就完全不一样了：
首先声明一个程序员接口：
interface IProgramer()
{
WriteCode();
}
然后声明两个类，并实现IProgramer接口：
class clsVBProgramer():IProgramer
{
....
WriteCode()
{
//用VB语言写代码；
}
....
}

class clsDelphiProgramer():IProgramer
{
....
WriteCode()
{
//用Delphi语言写代码；
}
....
}
对clsProject这个类进行一下修改：
class clsProject()
{
....
WritePrograme(IProgramer programer)
{
programer.WriteCode();//写代码
}
......
}

main()
{
clsProject proj=new clsProject;
IProgramer programer;
//如果需要用VB写代码
programer=new clsVBProgramer;
proj.WritePrograme(programer);
//如果需要用Delphi写代码
programer=new clsDelphiProgramer;
proj.WritePrograme(programer);
}
如果再有C#，C，C++，JAVA这样的程序员添加进来的话，我们只需把它们相关的类加进来，然后在main()中稍做修改就OK了。扩充性特别好！

另外我们如果把clsProject这个类封成一个组件，那么当我们的用户需要要扩充功能的时候，我们只需要在外部做很小的修改就能实现，可以说根本就用不着改动我们已经封好组件！是不是很方便，很强大！

[快意一剑]

分层开发时很有用，某些人只写业务接口，某些人只写实现业务接口，而某些人只是调用业务接口。这样有利于程序的分离

[浮生若梦丶]

我们定义一个接口
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()方法具体是如何实现的.比如,我们另外写了一个类.
public class Cat:IBark
{
public Cat()
{}
public void Bark()
{
Consol.write("喵喵");
}
}
当用户用到Cat类或是Dog类的时候,知道他们继承于IBark,那么不用管类里的具体实现,而就可以直接调用Bark()方法,因为这两个类中肯定有关于Bark()方法的具体实现.

如果我们从设计的角度来看.一个项目中用若干个类需要去编写,由于这些类比较复杂,工作量比较大,这样每个类就需要占用一个工作人员进行编写.比如A程序员去定Dog类,B程序员去写Cat类.这两个类本来没什么联系的,可是由于用户需要他们都实现一个关于"叫"的方法.这就要对他们进行一种约束.让他们都继承于IBark接口,目的是方便统一管理.另一个是方便调用.当然了,不使用接口一样可以达到目的.只不过这样的话,这种约束就不那么明显,如果这样类还有Duck类等等,比较多的时候难免有人会漏掉这样方法.所以说还是通过接口更可靠一些,约束力更强一些.

插件式框架作为一个高聚合低耦合的系统，它的功能定义与功能实现之间是分离的，这种策略是高聚合实现的保证。插件式框架好像一个功能聚集站，它对外界宣布，只要符合它发布的某种规范的组件（实现接口的类通常称为组件）都可以加入到这个平台中，而这些组件到底是做什么事情的，框架并不关心，当然，框架也提供了一些必要的信息和帮助保证这些组件能够正常实现它们的功能。
桥接模式是一种被认可的表示定义和与之关联的实现的方式，它和工厂（Factory）模式为所有的应用提供了基础。使用桥接模式开发的组件具有为了一个共同目标而多方协同工作除某些必须实现的接口外无需彼此交互的优点。
在具有多个逻辑层的程序设计中，各层之间的通讯大多通过接口实现，由于接口不会轻易改变，如果一个层的代码发生变化，它不会影响其它层的功能；只要实现接口的组件功能正确，那么这个程序运行就更无问题。这种做法使得各层之间的影响降低到最低程度。
接口是是类型一般行为的定义和契约。例如交通工具都包含启动、停车、加速和减速等方法，但作为交通工具的具体类型，不同车辆之间的操作是不一样的。接口并不考虑它们各自采用什么方式实现这些功能，但是，它们都必须有这些基本的功能。接口只负责定义而不考虑实现，我们也不能产生一个接口的实例对象（Instance）。
实现了接口的类或结构都必须实现接口中定义的每一个方法，这些方法在设计上往往是相关的。
接口与抽象类非常相似，例如两者都不能产生实例对象，都可以作为一种契约和定义使用。但接口和抽象类仍有本质的不同，这些不同包括：
1. 抽象类可以包含某些实现代码，但接口没有任何实现部分；
2. 抽象类可以包含字段而接口没有；
3. 接口可以被结构（Struct）继承，但抽象类不行；
4. 抽象类可以有构造函数和析构函数，而接口都没有；
5. 抽象类可以继承自其它类和接口而接口仅仅能继承自接口；
6. 接口支持多继承而抽象类仅仅支持单根继承。
下面是抽象类和接口的对比例子：
#001 public abstract class AClass {
#002 abstract public void MethodA (int a);
#003 abstract public void MethodB (int a);
#004 abstract public void MethodC (int a);
#005 abstract public void MethodD (int a);
#006 }
#001 public interface IInterface {
#002 void MethodA (int a);
#003 void MethodB (int a);
#004 void MethodC (int a);
#005 void MethodD (int a);
#006 }
即使不从桥接模式的观点考虑，多种面向对象语言都引入了接口这种类型定义还有一个重要原因：一个类可以实现多个接口。在大部分面向对象语言中，多重继承都是被禁止的，这是因为当编译器需要找到虚方法的正确实现时，会出现不确定性。但是接口并没有实现的部分，实现多个接口，并非意味着类（Class）那样的继承，它也绝非是多重继承机制的替代品。
我们常常将接口与抽象类混淆，事实上，两者的表象过于一致。但接口用来定义两个对象通信的契约，抽象类用来封装对象间公用的行为；抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。二者设计起初的目标完全不同，但在实际应用中被太多的人误解。这个原理在ArcObjects库中显露无遗：不同类型的组件互相调用是通过接口，而同一类型的对象群，如Color，则是通过抽象类组织在一起的，即接口是对外通讯的，抽象类是对内组织的。

[sunchaohuang]

接口可以使你的程序更加直观，当你需要了解这个程序实现了哪些功能时可以直接看接口类中的定义

比如基本操作类：
可以实现IDel,IAdd,IUpdate等相关的操作

还可以通过接口查找哪些类实现了相关的功能

接口一般在项目架构中的某个部分出现，使程序更加简洁美观，逻辑性强

[jryu2k5]

举个例子给LZ听听
假设有小车（car）一类，其中包含有行驶的方法（run），又道路一类（Path）
那么如何描述小车在道路中行驶呢？－》在path类中调用car类的run方法（就好似lz所说的一样）
又如何去描述道路的情况呢？这是不是就需要有一个car的list去记录所有在在路上的car，再去执行它们的run方法呢
但是在道路中不一定就只有小车，还可以有自行车（bike），行人（walker）
如果我们使用一个统一的方法名的集合Travel（接口，其包含run方法），去描述所有在路上的东西的行驶方法（run），然后所有的类（小车、自行车、行人）都实现该接口
那么在描述道路的情况的时候我们就不用建立每一个类的list去记录在路上的东西，只需要一个Travel的list，再去执行该接口的run方法就可以了
那不是比建立每个类的列表方便很多

简单而言，接口是一个统一的命名规范，它没法独立创建一个新的实例，只能够从承继于该接口的类中转化过来（不限任何类），换句话说，就好象父类跟子类一样，父类出现的地方子也可以出现；接口出现的地方，实现该接口的任何类都可以放到该地方！

[wuyq11]

接口的作用简单一点就是:接口是用来标记类的，不同的类属于不同的接口（通过向上转型），管理接口比管理各种各样的类方便多了，接口体现了抽象的观点
接口其实相当于一个标准，接口中的每一个方法、属性等对象，
使用接口可以规范一个项目的源码
接口中的定义为抽象定义，不需要 public private 等关键字
但是在实现的类中必须使用这些关键字去描述

[yunyouyou]

xuexi

[tmall_china]

学习了，努力学些！