在这里弱弱的问一声，接口在程序中到底起什么作用？谁有好一点的教程？最好从原理上解析的。
8 个解决方案
#1
看看面向对象的书吧。
#2
接口应该就是个规范吧，
看看面向接口编程的书籍吧
可以实现多态、减少耦合等
看看面向接口编程的书籍吧
可以实现多态、减少耦合等
#3
接口可以用来弥补C#里面类不能多重继承，因为接口是可以多重继承的.通过接口更可靠,约束力更强,易于维护
软件开发要针对接口编程，而不要针对实现编程
软件开发要针对接口编程，而不要针对实现编程
#4
接口就是实现类的多重继承的，
#5
我们在设计和编写程序的时候，有很多模块或者说是业务逻辑是会变化的，这会给我们在程序设计时带来很多不便，因为这些变化可能很小，但是我们却需要用不同的方法来实现，也许你会说“我可以用重载或重写”，但当这样的设计很多时就很难理解了。所以这时我们需要一个很好的设计原则，那就是“
把可能需要变化之处独立出来，不要和那些不变的代码混在一起”。就是说，把会变化的部分取出来并封装，好让其他部分不会受到影响。结果呢？变化带给我们的后果没有想象中的那么严重了，我们设计的系统变得更有弹性了。
我们也可以这样思考： 把会变化的部分取出来并封装起来，以便以后可以轻易地改动或扩充该部分，而不会影响不需要改变的其他部分。
如果你能领悟上面的意思，那么我下面就提出另一个原则： 针对接口编程，而不是针对实现编程。
以前我们可能会这么想：我们的某些行为(也就是我们的一些动作，方法)来自超类的具体实现或继承某个接口并有子类来实现。但是这样的做法都是依赖与“实现”，我们被实现绑定，没有办法更改行为。
所以我们以后要 针对接口编程，它的关键就在多态。利用多态，程序可以针对超类型编程，执行时会很据具体状态执行真正的行为，不会被帮死到超类的行为上。我想如果你能理解多态，上面这句话你肯定也能理解。
举个例子，说明一下多态：
class Duck{
quack(){
//鸭子超类的方法，说明每个鸭子都会叫,如果有些个别的鸭子有很好的天赋可以唱歌，那么就让它自己重新写吧。}
...
}
class ADuck extends Duck{
...
}
class BDuck extends Duck{
...
}
class main(){
Duck d1= new ADuck();
Duck d2 = new BDuck();
// 这里d1，d2都是Duck类型，但是它们却不是同一个子类的对象。实际运行时它们肯定不同。
//当然这里说的针对超类型编程，说的是，变量的声明类型是超类型，通常是一个抽象类或接口，如此，只要是实现以超类型的类所产生的对象，都可以指定给这个变量。
}
现在问题来了，我们的设计有些变化，我们的鸭子不只需要叫，还需要飞。那么这时你的想法是什么呢？在超类中放入fly方法，然后如果子类有需要就重写？如果是这样那就错了。万一以后有些鸭子不会飞，可怎么办，我们已经有了fly方法，呵呵。
所以这个时候用接口就是最好的了。
我们首先定义一个接口
public interface FlyBehavior{
void fly();
}
然后每个子类如果有会飞的能力，那我们绝对不会埋没人才，呵呵，让它实现FlyBehavior接口吧，然后自己来做具体的动作。
class CDuck extends Duck,FlyBehavior{
void fly(){
//重新实现自己想要的动作行为，实现了接口就必须这个接口的所有方法，所以这里必须实习fly方法，除非这个类是抽象类
}
}
你现在可能觉得，这样是不是得对每个会飞的鸭子实现具体的方法啊，可是很多方法是一样的啊，这样我们不是重复了么？
我这里还有一部分没有说，你继续看
我们定义一个类来实现刚才的接口
public class FlyWithWings extends FlyBehavior{
public void fly(){
//这里我们写下具体的飞行方法
}
}
然后修改我们刚才定义的鸭子C（CDuck ）
class CDuck extends Duck,FlyBehavior{
FlyBehavior flyWithWings;
CDuck(){
//我们在构造函数中初始化这个会飞的能力类
flyWithWings = new FlyWithWings();
}
void fly(){
flyWithWings.fly();
}
}
这样我们的杰作完成了，我们应用好多的知识。你自己总结一下吧！
我也只是写了接口的一部分功能，还有很多，我学的一不好，慢慢领悟吧，这里我引用了很多《head first设计模式》书的话和例子。
我们也可以这样思考： 把会变化的部分取出来并封装起来，以便以后可以轻易地改动或扩充该部分，而不会影响不需要改变的其他部分。
如果你能领悟上面的意思，那么我下面就提出另一个原则： 针对接口编程，而不是针对实现编程。
以前我们可能会这么想：我们的某些行为(也就是我们的一些动作，方法)来自超类的具体实现或继承某个接口并有子类来实现。但是这样的做法都是依赖与“实现”，我们被实现绑定，没有办法更改行为。
所以我们以后要 针对接口编程，它的关键就在多态。利用多态，程序可以针对超类型编程，执行时会很据具体状态执行真正的行为，不会被帮死到超类的行为上。我想如果你能理解多态，上面这句话你肯定也能理解。
举个例子，说明一下多态：
class Duck{
quack(){
//鸭子超类的方法，说明每个鸭子都会叫,如果有些个别的鸭子有很好的天赋可以唱歌，那么就让它自己重新写吧。}
...
}
class ADuck extends Duck{
...
}
class BDuck extends Duck{
...
}
class main(){
Duck d1= new ADuck();
Duck d2 = new BDuck();
// 这里d1，d2都是Duck类型，但是它们却不是同一个子类的对象。实际运行时它们肯定不同。
//当然这里说的针对超类型编程，说的是，变量的声明类型是超类型，通常是一个抽象类或接口，如此，只要是实现以超类型的类所产生的对象，都可以指定给这个变量。
}
现在问题来了，我们的设计有些变化，我们的鸭子不只需要叫，还需要飞。那么这时你的想法是什么呢？在超类中放入fly方法，然后如果子类有需要就重写？如果是这样那就错了。万一以后有些鸭子不会飞，可怎么办，我们已经有了fly方法，呵呵。
所以这个时候用接口就是最好的了。
我们首先定义一个接口
public interface FlyBehavior{
void fly();
}
然后每个子类如果有会飞的能力，那我们绝对不会埋没人才，呵呵，让它实现FlyBehavior接口吧，然后自己来做具体的动作。
class CDuck extends Duck,FlyBehavior{
void fly(){
//重新实现自己想要的动作行为，实现了接口就必须这个接口的所有方法，所以这里必须实习fly方法，除非这个类是抽象类
}
}
你现在可能觉得，这样是不是得对每个会飞的鸭子实现具体的方法啊，可是很多方法是一样的啊，这样我们不是重复了么？
我这里还有一部分没有说，你继续看
我们定义一个类来实现刚才的接口
public class FlyWithWings extends FlyBehavior{
public void fly(){
//这里我们写下具体的飞行方法
}
}
然后修改我们刚才定义的鸭子C（CDuck ）
class CDuck extends Duck,FlyBehavior{
FlyBehavior flyWithWings;
CDuck(){
//我们在构造函数中初始化这个会飞的能力类
flyWithWings = new FlyWithWings();
}
void fly(){
flyWithWings.fly();
}
}
这样我们的杰作完成了，我们应用好多的知识。你自己总结一下吧！
我也只是写了接口的一部分功能，还有很多，我学的一不好，慢慢领悟吧，这里我引用了很多《head first设计模式》书的话和例子。
#6
这个问题我现在的理解是为了规范化 至于接口有时用不上或者不用也可以不过系统复杂或者大了的时候会比较麻烦把
具体还是高手来指点
具体还是高手来指点
#7
顶下三楼，面向接口的编程
#8
接口 = 定义了要做的所有事情，但自己啥也不干
抽象类 = 做了部分共做，剩下的他不干了，等后来人继续完成
抽象类 = 做了部分共做，剩下的他不干了，等后来人继续完成
#1
看看面向对象的书吧。
#2
接口应该就是个规范吧，
看看面向接口编程的书籍吧
可以实现多态、减少耦合等
看看面向接口编程的书籍吧
可以实现多态、减少耦合等
#3
接口可以用来弥补C#里面类不能多重继承，因为接口是可以多重继承的.通过接口更可靠,约束力更强,易于维护
软件开发要针对接口编程，而不要针对实现编程
软件开发要针对接口编程，而不要针对实现编程
#4
接口就是实现类的多重继承的，
#5
我们在设计和编写程序的时候，有很多模块或者说是业务逻辑是会变化的，这会给我们在程序设计时带来很多不便，因为这些变化可能很小，但是我们却需要用不同的方法来实现，也许你会说“我可以用重载或重写”，但当这样的设计很多时就很难理解了。所以这时我们需要一个很好的设计原则，那就是“
把可能需要变化之处独立出来，不要和那些不变的代码混在一起”。就是说，把会变化的部分取出来并封装，好让其他部分不会受到影响。结果呢？变化带给我们的后果没有想象中的那么严重了，我们设计的系统变得更有弹性了。
我们也可以这样思考： 把会变化的部分取出来并封装起来，以便以后可以轻易地改动或扩充该部分，而不会影响不需要改变的其他部分。
如果你能领悟上面的意思，那么我下面就提出另一个原则： 针对接口编程，而不是针对实现编程。
以前我们可能会这么想：我们的某些行为(也就是我们的一些动作，方法)来自超类的具体实现或继承某个接口并有子类来实现。但是这样的做法都是依赖与“实现”，我们被实现绑定，没有办法更改行为。
所以我们以后要 针对接口编程，它的关键就在多态。利用多态，程序可以针对超类型编程，执行时会很据具体状态执行真正的行为，不会被帮死到超类的行为上。我想如果你能理解多态，上面这句话你肯定也能理解。
举个例子，说明一下多态：
class Duck{
quack(){
//鸭子超类的方法，说明每个鸭子都会叫,如果有些个别的鸭子有很好的天赋可以唱歌，那么就让它自己重新写吧。}
...
}
class ADuck extends Duck{
...
}
class BDuck extends Duck{
...
}
class main(){
Duck d1= new ADuck();
Duck d2 = new BDuck();
// 这里d1，d2都是Duck类型，但是它们却不是同一个子类的对象。实际运行时它们肯定不同。
//当然这里说的针对超类型编程，说的是，变量的声明类型是超类型，通常是一个抽象类或接口，如此，只要是实现以超类型的类所产生的对象，都可以指定给这个变量。
}
现在问题来了，我们的设计有些变化，我们的鸭子不只需要叫，还需要飞。那么这时你的想法是什么呢？在超类中放入fly方法，然后如果子类有需要就重写？如果是这样那就错了。万一以后有些鸭子不会飞，可怎么办，我们已经有了fly方法，呵呵。
所以这个时候用接口就是最好的了。
我们首先定义一个接口
public interface FlyBehavior{
void fly();
}
然后每个子类如果有会飞的能力，那我们绝对不会埋没人才，呵呵，让它实现FlyBehavior接口吧，然后自己来做具体的动作。
class CDuck extends Duck,FlyBehavior{
void fly(){
//重新实现自己想要的动作行为，实现了接口就必须这个接口的所有方法，所以这里必须实习fly方法，除非这个类是抽象类
}
}
你现在可能觉得，这样是不是得对每个会飞的鸭子实现具体的方法啊，可是很多方法是一样的啊，这样我们不是重复了么？
我这里还有一部分没有说，你继续看
我们定义一个类来实现刚才的接口
public class FlyWithWings extends FlyBehavior{
public void fly(){
//这里我们写下具体的飞行方法
}
}
然后修改我们刚才定义的鸭子C（CDuck ）
class CDuck extends Duck,FlyBehavior{
FlyBehavior flyWithWings;
CDuck(){
//我们在构造函数中初始化这个会飞的能力类
flyWithWings = new FlyWithWings();
}
void fly(){
flyWithWings.fly();
}
}
这样我们的杰作完成了，我们应用好多的知识。你自己总结一下吧！
我也只是写了接口的一部分功能，还有很多，我学的一不好，慢慢领悟吧，这里我引用了很多《head first设计模式》书的话和例子。
我们也可以这样思考： 把会变化的部分取出来并封装起来，以便以后可以轻易地改动或扩充该部分，而不会影响不需要改变的其他部分。
如果你能领悟上面的意思，那么我下面就提出另一个原则： 针对接口编程，而不是针对实现编程。
以前我们可能会这么想：我们的某些行为(也就是我们的一些动作，方法)来自超类的具体实现或继承某个接口并有子类来实现。但是这样的做法都是依赖与“实现”，我们被实现绑定，没有办法更改行为。
所以我们以后要 针对接口编程，它的关键就在多态。利用多态，程序可以针对超类型编程，执行时会很据具体状态执行真正的行为，不会被帮死到超类的行为上。我想如果你能理解多态，上面这句话你肯定也能理解。
举个例子，说明一下多态：
class Duck{
quack(){
//鸭子超类的方法，说明每个鸭子都会叫,如果有些个别的鸭子有很好的天赋可以唱歌，那么就让它自己重新写吧。}
...
}
class ADuck extends Duck{
...
}
class BDuck extends Duck{
...
}
class main(){
Duck d1= new ADuck();
Duck d2 = new BDuck();
// 这里d1，d2都是Duck类型，但是它们却不是同一个子类的对象。实际运行时它们肯定不同。
//当然这里说的针对超类型编程，说的是，变量的声明类型是超类型，通常是一个抽象类或接口，如此，只要是实现以超类型的类所产生的对象，都可以指定给这个变量。
}
现在问题来了，我们的设计有些变化，我们的鸭子不只需要叫，还需要飞。那么这时你的想法是什么呢？在超类中放入fly方法，然后如果子类有需要就重写？如果是这样那就错了。万一以后有些鸭子不会飞，可怎么办，我们已经有了fly方法，呵呵。
所以这个时候用接口就是最好的了。
我们首先定义一个接口
public interface FlyBehavior{
void fly();
}
然后每个子类如果有会飞的能力，那我们绝对不会埋没人才，呵呵，让它实现FlyBehavior接口吧，然后自己来做具体的动作。
class CDuck extends Duck,FlyBehavior{
void fly(){
//重新实现自己想要的动作行为，实现了接口就必须这个接口的所有方法，所以这里必须实习fly方法，除非这个类是抽象类
}
}
你现在可能觉得，这样是不是得对每个会飞的鸭子实现具体的方法啊，可是很多方法是一样的啊，这样我们不是重复了么？
我这里还有一部分没有说，你继续看
我们定义一个类来实现刚才的接口
public class FlyWithWings extends FlyBehavior{
public void fly(){
//这里我们写下具体的飞行方法
}
}
然后修改我们刚才定义的鸭子C（CDuck ）
class CDuck extends Duck,FlyBehavior{
FlyBehavior flyWithWings;
CDuck(){
//我们在构造函数中初始化这个会飞的能力类
flyWithWings = new FlyWithWings();
}
void fly(){
flyWithWings.fly();
}
}
这样我们的杰作完成了，我们应用好多的知识。你自己总结一下吧！
我也只是写了接口的一部分功能，还有很多，我学的一不好，慢慢领悟吧，这里我引用了很多《head first设计模式》书的话和例子。
#6
这个问题我现在的理解是为了规范化 至于接口有时用不上或者不用也可以不过系统复杂或者大了的时候会比较麻烦把
具体还是高手来指点
具体还是高手来指点
#7
顶下三楼，面向接口的编程
#8
接口 = 定义了要做的所有事情，但自己啥也不干
抽象类 = 做了部分共做，剩下的他不干了，等后来人继续完成
抽象类 = 做了部分共做，剩下的他不干了，等后来人继续完成