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