控制反转(IoC) ？ 工厂模式？

                                            

 

         不知道你们还记不记得当年程杰的《大话设计模式》了，最近一直想搞明白控制反转究竟是怎么回事，刚刚以为高大上了一点，而后再进一步去学习去对比的时候才发现，之前早就接触过这类的思想，设计原则的依赖倒转和设计模式的工厂方法都很好的体现了这种思想，火烧眉毛的想要跟你们分享一下啦！

 

1、依赖倒转原则

 

A.高层模块不该该依赖低层模块。两个都应该依赖于抽象。

B.抽象不该该依赖细节，细节应该依赖于抽象。说白了就是，要针对接口编程，不要对实现编程。

        在控制反转的原理中，咱们了解到，咱们将对象的实例化放到了容器中，在产品实现的时候，咱们直接调用接口，即容器将其所依赖的对象的引用传递到产品代码中。IoC管理对象间的依赖关系，产品代码只须要针对接口编程，而再也不依赖于具体实现。与依赖倒转原则一模一样。

 

                           

2、工厂方法模式

 

        定义一个用于建立对象的接口，让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。

工厂方法遵循开放-封闭原则，而且保持了封装对象建立过程的优势。

        咱们能够把IoC模式看作是工厂模式的升华，把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，而后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把之前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这二者独立分隔开来，目的就是提升灵活性和可维护性。

 

                   

 

3、反射

 

 

        工厂方法也有缺点，就是每加一个产品，就须要加一个产品工厂的类，增长了额外的开发量。不知道你们还记不记得在书里，写工厂方法的那一章，在最后一段话中，给你们留下了一个伏笔——反射。

        在后面讲到抽象工厂的时候，就提到了依赖注入的名词。就拿抽象工厂来讲，若是咱们须要新增一个数据库类型，就须要在代码中添加一条分支条件，破坏了开闭原则，这个时候依赖注入自己是没有能力解决这个问题的，可是若是咱们利用语言支持反射机制，利用反射配置数据源，就能够避免分支判断的问题。

        让咱们想一想，反射作了什么工做，咱们工程一开始的难点出在对象最后都是须要new，实例化的，而咱们只能实例化当前已有的类，不能对将来会添加的新类作处理，因此一旦有新的类加入，咱们就必须修改代码。可是，若是咱们有一种方法，不是经过new，而是经过类的名字来实例化对象，那么我只须要将类的名字做为配置项，就能够实现不修改代码的前提下加将来会出现的类。因此，咱们能够绝不夸张的说，反射给了语言“预见将来”的能力，使得多态性和依赖注入的威力大增。

 

4、结束语

 

          看了一大堆资料，把之前的设计模式也翻出来研究了一番，画画图，思路更加的清晰。IoC感受就像”抽象工厂+反射+配置文件“，如图，咱们能够把AbstractFactory做为IoC容器，而且加入反射机制和配置文件，实现灵活配置类名。（解释，配置文件取代ConcreFactory1和ConcreFactory2，具体用哪一个，灵活配置类名便可；反射用在AbstractFactory里，取代分支判断，避免了后期扩展修改代码的弊病）

                                

 

         OK，面向对象无外乎那几个原则，大道至简的路，还很漫长，java的学习，才刚刚开始，加油吧！