为什么要针对接口编程

接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。


接口反映了系统设计人员对系统的抽象理解的程度。


接口都是在一定的环境中产生的。脱离原先的环境，所有的接口将失去原有的意义。

-----------------------------------------------
接口统一了，实现可以千差万别，我们都可以按相同的方式访问。拿JDBC来说，很多东西都是接口，实际上就像是个架子，各个不同的数据库厂商或者第三方根据这个框架往里面塞具体的驱动实现，对于JDBC的使用者而言，这些都不必关心，按着JDBC的统一方式访问数据库就可以了，很多时候这样做也带来代码重用的方便，对不同的数据库，只需要修改少量参数而不必修改具体访问细节，而这一步也很容易放到具体程序之外，从而使代码尽可能的独立于具体的数据库，这对于程序的维护是很有好处的。

对于用户是不是真的需要知道具体类，我想：
1、就算真的需要知道具体的类，在类的对象产生后还有一个如何操纵对象的问题，假如程序中需要的具体对象所属的类不一样，但接口一致的话，那么我们很容易以利用多态写出更简洁且容易扩展的代码。
2、很多时候对象的最终的使用者和类/对象的构造者并不是同一个人，他们之间还需要一个抽象层作为contract，这个时候接口的作用还是很明显，就像前边提到的JDBC。

------------------------------------------------
有人提问:尽量少用接口行不行? 
请看这个帖子:
http://www.iteye.com/topic/1120032?page=3

cataclyzh 写道

碰到一个项目,许多只有一个实例的类也定义了接口,而且这些类还经常要添加方法.结果偷懒的人就在使用到接口的地方直接一个强制装换.

比如函数中传递了IObjectManager接口的,这个接口里面原来只有一个search(String id)方法,后来实现类经常添加方法,修改的人每次改了实现后还要在添加接口定义.结果有些地方的调用就出现了这样的代码:
((IObjectManagerImpl)IObjectManager).search(obj)

问题是这样的代码还运行的挺好的,历经测试,一直延续到最新的版本.

写这样的调用确实不好.但也算事出有因.因为不当的接口使用增加了编码的工作量.

想了想自己使用接口的地方不算多,主要是:
1. 一个接口有多个实现.最常见的是定义事件监听.
2. 需要交给Spring管理的类(一般是DAO层和service层的类).
其他的地方一般先不考虑定义接口.以后有需要了,再加.

思考的好啊! 这种思考是实践之后做出的思考,比其它人只看书本人云亦云未经实践总结就说出来的一套套理论好多了.

写与不写接口,这种大家每天都在做的平常平常平常平常事儿,是很难以讨论难以达成共识的,因为人人天天都在做这件事儿,人人都有自己的观点与看法,人人都认为自己的做法是正确的才去行动,没有人认为自己做的是不对的.

平凡中见真谛,这种思考不应该被投隐藏贴.应积极讨论,百家争鸣.


前面有人提到了JDBC的接口,JDBC的接口用的好啊, 太好了.没人说不好.  因为没有接口JDBC就不能活.
SUN公司定义JDBC规范时若不使用接口, 真没有别的方法.
比如说SUN公司1990年制定的JDBC规范(不知具体哪年), 2000年时问世了一个新数据库A公司,实现了JDBC规范,之后大家就可以使用A公司的数据库了.  所有程序员惊呼----接口万岁,并发誓以后我也充分运用接口.

比如说Apache 2008年开发了Struts2(不知具体哪年),C人2010年开始使用Struts2,并发现默认配置不能满足业务,所以他针对Struts2的接口做了扩展.  所有程序员惊呼----接口万岁,并发誓以后我也充分运用接口.

请注意以上两个事儿共有的3个特点:
1.一个接口有多个实现类(必需是多个,不然说服力不够)
2.有两个角色,SUN公司--A公司,Struts2--C人
3.有时间差,1990年--2000年,2008年--2010年
以上三点太重要了,请先记住.


转眼间到了2012年 ,cataclyzh(楼主)等人  开始开发自己公司的项目,这是一个以增删改查为主的项目,是最帖近用户的项目,并非JDBC,Struts2一类给程序使用的项目.  并定下目标,要写最好的程序:有良好的扩展性,有高质量的代码,有快速跟进用户需求变化的能力,等等..... 

项目开发中.... 一个月,两个月...八个月...
cataclyzh(楼主)等人遇到的第一难题是:用户需求一变再变
cataclyzh(楼主)等人遇到的第二难题是:交付日期一推再推
经理的脸色越来越难看, 大家开始加班,加班,加班 .修改,修改,修改.

cataclyzh(楼主)等人 开始抱怨:实现类经常添加方法和修改,修改的人每次向实现类加了新方法后,还要在接口加添加同样的方法名,甚至项目组里有人偷懒写了楼主说的强制转换代码. 请大家注意这个顺序,是先改实现类,再把代码COPY到接口当中修改接口.完全不是大家预先设想的先定义接口,后写实现类,现在的情形与书中例子说的接口的好处,与其它人的说的接口的好处截然不同,到目前为止cataclyzh(楼主)等人没有体会接口的半点好处.就陷入了深深的思考/深深的思考/深深的思考.

其实这种"快速跟进用户需求变化"的项目,接口是很难抽象出来的(主要是增删改查的业务部分).

当cataclyzh(楼主)等人困惑时,来ITEYE发贴求问,还被投了隐藏贴.   ,在这里我投你一个精华


还记得前面提到了  "共有的3个特点" 吗? 我们来分析一下,cataclyzh(楼主)所在的项目, 拥有几个?
1.一个接口有多个实现类-- 没有,cataclyzh(楼主)的接口只有一个实现类.
2.有两个角色--没有,永远是cataclyzh(楼主)这一个项目组的三五个人.同一个项目组算一个角色.
3.有时间差--或许有但不明显,基本都是当年或两一二年的项目.

经理的脸色越来越难看,所以眼前的情形是要应付的, 但也要有长远的目光.接口带来的好处是有目共睹的.cataclyzh(楼主)如果想收获接口带来的好处, 还需要先顶过目前的难关,再未来扩展时或许会收获到. 这还是一个"或许",因为但愿你公司的这个最贴近用户的产品还有扩展的机会.jdbc扩展的机会是无限大的不会消失,但你的产品....
这时候"敏捷"更重要.




最后再重复一次前面说过的话:写与不写接口,这种大家每天都在做的平常平常平常平常事儿,是很难以讨论难以达成共识的,因为人人天天都在做这件事儿,人人都有自己的观点与看法,人人都认为自己的做法是正确的才去行动,没有人认为自己做的是不对的.