面向接口编程
近期在对一个现成项目进行修改、扩展。里面的代码很乱,业务逻辑、数据库操作全部都混合充斥在页面代码中。
藉重构之机,当然首要是将业务逻辑和数据库操作从页面代码中剥离。在这里,我使用了接口。面向接口编程。写了一些具体的类来实现业务和数据库操作。这些类都继承接口;WEB端也通过接口来调用这些类,由简单工厂返回这些类的实例。这样,WEB、服务中间由接口分隔开,WEB只管调用,服务只管实现,大家都面向接口编程,各自独立地演化(靠,这是桥接模式?),酷吧?
“有什么必要用到接口呢?”,同事问
“如果业务逻辑变了,只修改服务即可,WEB可以不用改啊”,我教条地说
“可是业务逻辑变了,通常接口也会变的吧,如果有接口的话;并且每次都要先改接口,再改实现类,麻烦得很”
“哦……面向接口编程……是……设计模式原则之一……隔离……约定……@#%……¥……”我弱弱地搬出一些高大上的名词,试图装腔作势。
究竟,面向接口编程的必要性在哪里呢?
我想了一下,总结如下:
1、调用与实现分离,利于修改和扩展
2、逻辑清晰,令开发者赏心悦目,心情舒畅
3、接口有约束性,利于统一
4、接口要频繁更改,是设计的问题;另外,接口也应该尽量细粒度
网上摘录:
面向接口编程就是先把客户的业务提取出来,作为接口。业务具体实现通过该接口的实现类来完成。当客户需求变化时,只需编写该业务逻辑的新的实现类,通过更改配置文件(例如Spring框架)中该接口的实现类就可以完成需求,不需要改写现有代码,减少对系统的影响。采用基于接口编程的项目,业务逻辑清晰,代码易懂,方便扩展,可维护性强。
但是我们为什么体会不出什么好处,因为我们的系统很小,协助开发较少,接口设计也不合理,往往需要变了接口也要变,理论上当需求变化的时候我们只需要修改接口实现。
版权声明:本文为博主原屙文章,喜欢你就担走。