上一章，我们建立了模拟服务项目对表现层提供服务，表现层直接依赖于服务层的具体类，如图：（以下所有图中，底色为红色的代表类，蓝色代表接口）
这样带来的缺点就是，当模拟服务对象发生变化的时候，会影响到表现层。我们知道，三层架构的目的之一就是当一层发生变化的时候尽量不会影响到其他的层。因此，我们要对我们的项目做一些调整，使表现层和服务层解耦，同时也为以后将模拟服务对象替换为真正的服务对象时作准备。
关于接口、依赖倒置、工厂模式在此不再介绍了，推荐《HeadFirst设计模式》一书。
接口带来的好处就是，只要接口不变化，接口两端的对象发生的变化不会对另一端造成影响。见下图：
现在，表现层和模拟服务对象都依赖于服务接口。当模拟服务对象的实现发生变化的时候，只要接口不发生变化，表现层的实现就不需要发生任何变化，反之亦然。
并且，当添加真正的服务对象的时候，表现层所做的修改也很少。如图
但是多多少少都得改点，因为我们的对象都是new出来的，这些零碎的改动也相当不爽，因此我们用工厂模式，使得只需要替换不同的工厂即可。如图
不过，值得一提的是，接口并不是万能的。刚才所做的一切前提就是接口不发生变化。接口一旦发生变化，接口两端的对象都必须做出相应的调整。
更进一步的，我们可以用反射来创建工厂类，从而不用重新编译程序，只需要更改配置文件即可替换整个业务服务层。
