1 什么是接口
接口是一种用来定义程序的协议，它描述可属于任何类或结构的一组相关行为。
接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是……则必须能……”的理念。
接口是在一定粒度视图上同类事物的抽象表示。因为“同类事物”这个概念是相对的，它因为粒度视图不同而不同。
2 为什么要使用接口？而不是直接实现呢？
接口的使用并非总是从设计的角度来考虑。接口和python其他语法现象一样，共同构成了python整个语言体系。
接口的意义在于 抽象、不拘细节,从而使同类事物在同一高度具有通用及可替代性。
关于解耦，并不是接口能解耦，而是抽象能解耦 接口只是手段,如果两个事物有必然联系，那么就不会出现完全解耦，只能耦合转移。
—— from http://bbs.csdn.net/topics/380040137
在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。
- 系统灵活性增强
当下层需要改变时，只要接口及接口功能不变，则上层不用做任何修改。甚至可以在不改动上层代码时将下层整个替换掉，就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。 - 不同部件或层次的开发人员可以并行开工
就像造硬盘的不用等造CPU的，也不用等造显示器的，只要接口一致，设计合理，完全可以并行进行开发，从而提高效率。
那么具体什么时候用，什么时候不用呢？在常见的三层架构中，有以下几个层次，分别进行说明:
- 界面层
也就是展示层，直接呈现给用户的，可能不同的软件有不同的呈现方式，比如Web，WinForm,甚至移动APP，在这个层次，我认为是没有必要写太多的接口。 - 业务逻辑层
这个层次，业务逻辑，可以根据需要使用接口。如果是直接读写数据库什么的，就直接用调用数据库访问层的接口。如果是与多个第三方接口进行交互，那么就需要接口，不同的渠道各自实现。 - 数据访问层 数据访问层，最好使用接口，比如数据库访问，这种可以根据不同的数据库实现相应的接口向业务逻辑层提供服务。
可能在开发的时候，一开始我们并没有想到要使用接口。可能简单就用一个类实现了。到后面新的需求过来的时候，发现代码需要重构，要用接口和抽象类等等。这个也需要看个人编码的习惯。有的人就长篇大论一个类完成所有的逻辑。这样的开发人员，应该是很少见过好的代码，如果见过的话，后面肯定会精简做到更好。而另外一些人可能一开始就能嗅出来哪些地方需要使用接口，哪些地方使用抽象类，这也是一种思维方式。前面一种只管开发当前的功能。而后面一种则会考虑到以后的扩展。总而言之，需要根据不同的情况进行考虑。
2.1 面向接口编程
面向接口编程：面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其一部分。或者说，它是面向对象编程体系中的思想精髓之一.
2.2 软件设计中有关接口的原则
我一直认为这个问题，应该从设计的角度来讲。在软件设计的六大设计原则中，与接口直接相关的就有以下两个：
- 依赖倒置原则 高层模块不应该依赖底层模块，二则都应该依赖其抽象，抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：面向接口编程,将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。 - 接口隔离原则 定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：在设计接口的时候要精简单一,将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。 - 总结
单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。接口在设计模式中，有很多的灵活应用。
