依赖倒置原则与springIOC学习

设计模式之——依赖倒转原则初识依赖倒转、控制反转、依赖注入三者含义和目标基本一致，即通过抽象接口解耦和消除依赖关系依赖倒置的核心思想是依赖于抽象。1、高层模块不应该依赖低层模块，两者都应该依赖其抽象；2、抽象不应该依赖细节；3、细节应该依赖抽象。高层模块和低层模块：每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。细节和抽象：在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是：1、模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；2、接口或抽象类不依赖于实现类；3、实现类依赖接口或抽象类。一句话：面向接口编程反例：代码：司机通过调用奔驰车的run方法开动奔驰车publicclassDriver{//司机的主要职责就是驾驶汽车publicvoiddrive(Benzbenz){benz.run();}}publicclassBenz{//汽车肯定会跑publicvoidrun(){System.out.println(奔驰汽车开始运行...);}}有车，有司机，在Client场景类产生相应的对象publicclassClient{publicstaticvoidmain(String[]args){DriverzhangSan=newDriver();Benzbenz=newBenz();//张三开奔驰车zhangSan.drive(benz);}}通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。但是业务需求变更永无休止，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？我们先把宝马车产生出来publicclassBMW{//宝马车当然也可以开动了publicvoidrun(){System.out.println(宝马汽车开始运行...);}}宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？因为张三没有开动宝马车的方法。一个司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题：司机类和奔驰车类之间是一个紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本。从这里，我们知道使用抽象才能解决这个问题。稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。”减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。一个团队，20人开发，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续…，这在90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作，但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队的协作结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！正例：publicinterfaceIDriver{//是司机就应该会驾驶汽车publicvoiddrive(ICarcar);}publicclassDriverimplementsIDriver{//司机的主要职责就是驾驶汽车publicvoiddrive(ICarcar){car.run();}}publicinterfaceICar{//是汽车就应该能跑publicvoidrun();}publicclassBenzimplementsICar{//汽车肯定会跑publicvoidrun(){System.out.println(奔驰汽车开始运行...);}}publicclassBMWimplementsICar{//宝马车当然也可以开动了publicvoidrun(){System.out.println(宝马汽车开始运行...);}}业务场景中使用时：publicclassClient{publicstaticvoidmain(String[]args){IDriverzhangSan=newDriver();ICarbenz=newBenz();//张三开奔驰车zhangSan.drive(benz);}}在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降低到最小。注意在Java中，只要定义变量就必然要有类型，一个变量可以有两个类型：显示类型和真实类型，显示类型是在定义的时候赋予的类型，真实类型是对象的类型，如zhangSan的显示类型是IDriver，真实类型是Driver小结：抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不逃脱契约的范畴，确保约束双方按照既定的契约(抽象)共同发展，只要抽象这根基线在，细节就逃脱不了这个圈圈。最佳实践：1、每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。2、变量的显示类型尽量是接口或者是抽象类。很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的3、任何类都不应该从具体类派生。如果一个项目处于开发状态，确实不应该有从具体类派生出的子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再要去继承最高的基类呢？4、尽量不要覆写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。5、结合里氏替换原则使用（父类出现的地方子类就能出现）讲了这么多，那到底什么是“倒置”呢？我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。SpringIOC（InversionofControl）、DI（DependencyInjection）IoC控制反转（也称作依赖性注入DI）是Spring的核心他的基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。Spring中的IoC容器负责将这些联系在一起。在典型的IOC场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，由容器来决定什么时间调用方法例子：Spring配置：1、setter方法注入beanid=“bclass=“bpropertyname=“aref=“a//beanbeanid=“aclass=“a//beans2、constructor构造函数注入beanid=“bclass=“bconstructor-argref=“a//beanbeanid=“aclass=“a//beansSpring的核心容器IOC就是提供对象的配置管理功能。Spring中IOC的基本概念是：基于OO设计原则的TheHollywoodPrinciple：Don’tcallus,we’llcallyou（别找我，我会来找你的）。程序中各个组件之间的关系，不由程序代码直接操控，而由容器控制。控制权由应用代码中转到了外部容器，即所谓的反转。也就是说对象的控制权转交给spring容器。直接点说：1、不用再去NEW对象了，之所以少写new，是因为系统的配置（即第三方的管理）2、面向接口，符合OO（ObjectOriented)3、系统的可扩展与代码的易维护spring小结将对象交与IOC容器管理，避免在程序中出现具体实现。通过代码我们可以看出IOC依赖注入的好处:1.对象之间的依赖关系,不由对象自身来负责,而是由容器依据配置文件动态建立，这样就很灵活，可配。2.采用依赖注入,模块之间一定是松散耦合的3.代码易维护易测试如果不使用框架，我们传统的写法一般是自己建立工厂或者用单例来处理业务层与Dao层，而使用了Spring，这些工作我们就都不用管了。依赖倒置、控制反转、依赖注入区别：依赖倒置、控制反转和依赖注入的区分依赖倒置、控制反转和依赖注入从思想来讲是统一的，或者说是类似的，有人也说它们是同一个东西。但是还是可以做一点区分：1、依赖倒置原则：是进行软件设计时考虑遵循的一个原则。具体为：（1）上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。（2）抽象不能依赖于具象，具象依赖于抽象。2、控制反转：是软件运行时体现出来的一个特征：如果对象A运行时依赖于对象B，但A并不去创建B，而是从外界直接取得B。也就是说，一个对象并不是自己去创建它所依赖的其它对象。3、依赖注入：是控制反转的一种实现手段。如上面的例子，B的取得并不需要A的干涉，而是利用某些框架在通过构造参数或属性设置来实现。。弊病依赖倒置的基础是假设抽象是稳定的。对于我们已经了解的事物，当然可以实现很好的抽象，但对于尚未认识清楚的事物，比如用户需求，就很难保证这个抽象的稳定性。因此一旦这个抽象稳定的假设不成立，那么依赖倒置不但不能发挥优势，反倒可能成为包袱。优点相对于细节的多变性，抽象的东西要稳定的多。遵循依赖倒置原则的好处是可以降低类之间的耦合性，提高程序的稳定，同时也方便修改代码以实现程序的新功能。