我理解的面向接口编程

从题外话说起，在古代没有货币的时候，人们只能用某一样东西去换取自己需要的另一样东西。比如，张三需要一匹布，李四需要一头鹅，正巧张三有一头鹅，李四有一匹布，于是他们达成了共识，拿布与鹅进行交换，各取所需。但这种交易有很大的弊端，那就是交换物的不确定性，李四想要的是鹅，王五想要的可能是牛，赵六想要的可能是羊。如果张三想要跟不同的人进行交易，那么他需要准备很多很多的东西。每个人都需要用这种方法进行交易的话，将会特别的混乱和麻烦。于是，作为一般等价物的货币诞生了，在一定程度上解决了这种问题。

但是随着社会的发展进步，现实的货币已经不足以满足人们在交易便捷上的需求。当你要去世界各地旅游的时候，各个国家和地区的流通货币是不一致的，在中国用人民币，去日本你要用日元，去美国你要用美金，去欧洲你要用欧元，从德国去到英国，你还需要把欧元兑换成英镑，如果去的地方多了，这么多个国家的货币换来换去也是很不方便的。于是有了虚拟的货币形式。现如今，你已经不再需要牵着几头牛几只羊去跟别人做交换，也不需要带着各种货币，而只要有一张VISA信用卡，去到世界各地，美金你能刷，日元你能刷，欧元你能刷，英镑你还是能刷，想去哪里想买什么你都是刷刷刷，可以说是：一卡在手，走遍世界。是不是觉得很方便。这就实现了：从猪牛羊等实物的交易，到现实货币的交易，再到“面向信用卡交易”的转变。

面向信用卡交易，好处就在于：你不需要知道两头牛对应几只羊，也不需要在各国的货币之间换来换去，你更不需要知道信用卡是如何工作的，你唯一需要确定的，就是你余额足够。然后剩下的一切，交给信用卡去完成就可以了。

我把面向接口编程中的“面向接口”，理解成为上文所谈到的“面向信用卡”，接口就是我们的信用卡。

在面向过程的开发中，上层调用下层，上层依赖下层，在“金字塔”的模式下，越往下层就会越庞大，一个上层往往对应很多很多个下层，一旦有一个下层有发生变动，上层也必须作出相应的改变，如果很多很多个下层都发生改变，上层就几乎是不可维护的。这样一来，“上层依赖下层”这种依赖关系，会造成很多问题。

因此在面向对象的开发中，采用了“面向接口编程”来解决这样的问题，核心思想是“依赖倒置”：

1、上层的模块不应该依赖于下层的模块，他们都应该依赖于抽象。

也就相当于上面所谈到的，我们去世界各地买东西（交易——“上层模块”），不依赖于猪牛羊（货物——“下层模块”），也不依赖于现实的货币（下层模块），我们依赖的是我们的VISA信用卡（抽象）。

2、抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

也就是说，我们的VISA信用卡（抽象）不需要依赖于美元（具体）、日元（具体）、人民币（具体），而是让美元、日元、人民币来依赖信用卡。实际上，也确实如此。

在MVC模式下，“面向接口编程”是下图这样的关系

在面向接口CustomerDAO之前，CustomerServlet依赖实现类CustomerDAO_impl（JDBC实现类）和CustomerDao_xml_impl（XML实现类），CustomerServlet中的代码是这样的：

下层（实现类）发生了修改，上层（CustomerServlet）也要跟着做出修改。当下层很多，修改很多的时候，上层模块几乎不可维护。

在面向接口CustomerDAO之后，CustomerServlet中的代码是这样的：

让下层的具体实现类去依赖接口，通过多态来创建实现类的对象，不管下层（实现类）如何修改，如何增加，上层代码（CustomerServlet）都是不需要修改的，这就有了很强的可维护性。