对象引用------》接口-------》工厂设计模式------》依赖注入
1.第一个阶段：直接引用对象实例
例如模块A中依赖模块B中的Car类实例
Benz car=new Beaz();
这种依赖于具体的实现类是最不稳定的，若果更换了具体实现类，这样客户端A的所有依赖具体实现类的操作调用都需要改变
情境模拟： 客户跟汽车租赁商租赁一辆由汽车生产厂商生产的独特奔驰轿车。
存在的问题：
a.我在跟汽车租赁商签订合同之后我需要拿着合同去汽车生产厂商那里提车（客户本依赖于租赁商，后依赖了生产厂商）
b.该车有自己独特的驾驶方式和使用方式，我需要学习（使用方式强耦合具体车型 ）
c.该车出现问题之后我需要跑到对应的生产商那里去修车。（同a的问题）
2.第二阶段：通过接口降低耦合性，只解决了问题b
Car car=new Benz();
发展到这个阶段，车辆租赁也发现阶段一的问题所在了，好，那我做出一些修改，例如厂商更具车辆的使用共性，我制定一些通用的使用方法，例如驾驶方法（以后所有的车辆驾驶方式都遵循该设计模式），用户只需要学习通用的驾驶方式就可以了，我只要会开车，不管该租赁提供什么车，我都能驾驶上路，就不用针对每种不同类型的车学习相应的驾驶技术了，也就降低了使用方面的耦合性，把抽象的共有使用通过接口结合起来，这种方式还是存在依赖性的问题，没有降低对于厂商的依赖性的问题
3.第三阶段：通过工厂设计模式
Car car=CarFarctory.getInstance("benz");
汽车租赁商发展到现在也发现第二阶段的问题了，汽车租赁商把不同类型的汽车从各个厂商买过来，自己培养一批专业的修理技师，那不就解决了b,c问题了吗。所以对应客户来说我只需要跟汽车租赁商产生关系，耦合性降低了很多啊，但是客户端的交通出行还是会根据汽车租赁厂商的车类型有关。
4.第四阶段：通过依赖注入更加极致的降低耦合性
@Autowired
private Car car;
简单的解释一下依赖注入，更加明确的解释自查，什么是依赖注入：我需要的时候你在提供给我。
其实我们仔细分析我们的需求，可以发现我们租车是为了出行，那这样的话如果有一种提供出行服务的公司不就更好吗？此时租赁公司提供出租业务---滴滴闪耀登场，就解决了客户需需要跑到租赁公司租车的这一步，此时客户端创建实例的职责就相应的转移到了依赖注入框架，我不管租赁公司具体的实现方式，我在我需要出行的时候叫个滴滴就能完美解决我的出行问题。模块A和模块B的依赖降到了最低.
参考资料
[接口与耦合]（blog.csdn.net/qi184043977…
[依赖注入--维基百科]（en.wikipedia.org/wiki/Depend…
