在项目中的意义:
在传统的项目开发过程中,由于客户的需求经常变化,如果不采用面向接口编程,那么我们必须不停改写现有的业务代码。改写代码可能产生新的BUG,而且改写代码还会影响到调用该业务的类,可能全都需要修改,影响系统本身的稳定性。而且为了将改写代码带来的影响最小,我们不得不屈服当前的系统状况来完成设计,代码质量和稳定性更低。当这种情况积累到一定程度时,系统就会出现不可预计的错误,代码凌乱,不易读懂,后接手的人无法读懂代码,系统的维护工作越来越重,最终可能导致项目失败。
接口在项目就是一个业务逻辑,
面向接口编程就是先把客户的业务提取出来,作为接口。业务具体实现通过该接口的实现类来完成。当客户需求变化时,只需编写该业务逻辑的新的实现类,通过更改配置文件(例如Spring框架)中该接口的实现类就可以完成需求,不需要改写现有代码,减少对系统的影响。
采用基于接口编程的项目,业务逻辑清晰,代码易懂,方便扩展,可维护性强。即使更换一批人员,新来的人依然可以快速上手。对于公司来说,意义更大。
在Java中的意义:
Java本身也是一个不断完善的语言,他也在频繁的改动他的系统API来完善,他的API是一个庞大的体系,互相关联,如果不采用接口,而都是用实现类的话,那么API的改动就会给整个体系带来不稳定。而且如果改动API,那么就会有大量采用旧API的项目因无法正常运行,会损失大量客户。换句话说,JDK已经发布的API是一种承诺,一经发布就不能更改,即使原来API存在各种各样的问题(例如java.util.Properties类就是一个失败的例子)也必须保留,于是在Java里就出现了不建议使用的方法,但JDK依然提供该方法。而且Java语言本身是一个跨平台的语言,为了满足在各个平台下运行,就必须把各种操作做成接口,在编写各个平台下的实现类。
设计模式的体现:
在设计模式的原则里的开闭原则,其实就是要使用接口来实现对扩展开放,对修改关闭。在设计模式的其他原则里也有关于基于接口编程的原则,即依赖倒转的设计原则(DIP)----高层模块不应该依赖于底层模块。二者都应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象(注:来自《敏捷软件开发--原则、模式与实践》Robert C.Martin著)。在使用面向接口的编程过程中,将具体逻辑与实现分开,减少了各个类之间的相互依赖,当各个类变化时,不需要对已经编写的系统进行改动,添加新的实现类就可以了,不在担心新改动的类对系统的其他模块造成影响。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为:
只有实现者和调用者都遵循“面向接口编程”这个准则,制定者的协调目的才能达到。
一个老生常谈的例子就是JDBC。
优点:
接口和实现分离了,适于团队的协作开发。
主要为了实现松散耦合的系统,便于以后升级,扩展。
缺点:
设计难了,在你没有写实现的时候,就得想好接口,接口一变,全部乱套,这就是所谓的设计比实现难。
所以设计接口的人工资都高啊!!!