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

                                      


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

 

一、依赖倒转原则

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

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

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

 

                           

二、工厂方法模式

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

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

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

 

                   


 

三、反射

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

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

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

 

四、结束语

 

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

                                


 

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