重新认识IOC & DI -- Head First Design Patterns 读书笔记（二）

    这本书是基于Java来写Patterns实现的，但是很多有多年J2EE程序开发经验的人可能都没有对Patterns有很深入的了解，因为J2EE基本上都是一个MVC的模式就全部搞定了，开发的时候层次完全划分好，即便是有一些继承的类或者借口也都是项目组中一、二个“牛人”写好大家遵照着做就可以，我想这也是Patterns对于国内程序员一直都很陌生而且不易于理解的原因吧。

     所以一提到设计模式，几乎所有做J2EE的程序员第一时间想到的都是Factory Method，让举个例子就是Singleton method，然后再深入说说使用工厂模式有什么好处呢，就开始支支吾吾。我就是这样，而我所接触的一些程序员和我面试过的一些人无不如此 ：P，也许冥冥中注定大家都只是打字员的命，那些高深的东西都留给所谓的大师去做好拉！（不知道大家怎么去考虑这个问题）

     虽然说了解最多的就是Factory Method，但是在仔细阅读了书中的Factory Method和Singleton Method之后，发现自己还是非常嫩 ：（。特别是通过这次阅读学习，偶发现我以前对IOC和DI的理解也是错误的，一道纠正写在这里好了。

所有语义、使用场景和优点在读书笔记一中进行总结。

     一、Factory Method 

     首先发现的一个我常犯的错误就是：抽象工厂不是将工厂方法抽象出来。因为从来没有实际操作过，所以一直以为Abstract Factory是将Factory mothod抽象出来的Abstract class，实际上他们直接并没有直接联系，Abstract Factory只是一个接口类，其中定义了若干个对象的创建，然后由其他类实现以达到解藕的目的而已。工厂方法仍然是我们所熟悉的那个为避免过多的使用new创造对象而将创建过程提取出来的那个Pattern，而且通常情况下工厂方法是使用的抽象类，并在其中定义一个抽象方法来实现的，目的是为了解偶，当然，有时候也可是直接将创建方法写进具体的类里面。使用工厂方法一般是在只需要一个固定的构造器的时候用来解偶用的，那么当你增加产品或者修改产品的实现的时候，它不会影响到你的构造器，因为构造器并没有紧耦合。

     二、 Abstract Factory Method

     而抽象工厂模式则提供一个接口来创建一组有关联的对象而不去指定它们的具体实现类，而我们最常见的就是Spring中的Inversion of control。在以往使用Spring的过程中我一直没有能将IOC这个概念吃透，虽然这并不影响使用，但是每当我想说服他人使用Spring的时候或讲解其机理的时候就会非常的吃力，而现在我有一点小感想了，IOC只是一个抽象工厂的实现，那么什么控制反转、什么依赖注入这种生涩的概念我就可以先不予考虑，它首先就是一个抽象工厂的实现，创造一组对象的接口而没有指明具体的实现类（这样考虑感觉一下就容易多了）。具体的解释可以参照老马的经典文章：http://martinfowler.com/articles/injection.html，那么从这里可以得知，实现依赖注入他推荐使用构造方法的注入，而在不能满足条件的情况下使用set方法设值注入，而Spring选择的就是set方法，可能这个就是让我们不好理解的地方，因为我们是先学写代码后学框架然后才学Patterns（不知道其他人是否也是这个顺序），或者说对代码、框架有了一定了解后才有了对Patterns的了解。

     三、IOC & DI

     那么我们就从IOC这个抽象工厂开始，书中提出一个简单的例子让我们了解了抽象工厂的用意就是使用接口来指定构造那些对象而没有指定具体的实现类，以达到解偶的目的，使得对象的使用者并不知道最终调用的具体类，而是在运行期动态的注入了一个实现该工厂接口的值来决定最终调用哪个类去实现。这就是书中对Inversion of control的解释，也就是说low level component方向控制了high level component，达到控制反转的目的。然后我们翻开很久以前就熟读过的SpringGuide文档，发现这里面对IOC还有另外一种解释，就是用容易控制了程序之间的关系，而非传统实现中，由程序代码直接操控。这样控制反转的两种方式就出现了，也就是先前老马在文中所说：IOC的实现可以通过两种途径，一是通过编码、二是通过配置文件。（这个地方可能还有些出入，需要更深入的学习和讨论才会有更深入、准确的理解）

     四、Singlton Factory

     尽管我们对构造Singlton Factory可能很熟练，但是书中还是很详细的写出3种构造方法，并由最简单的方式逐渐提出新的需求和问题以讲述我们到底需要哪种方式。

     比如我们经常会看到的public static synchronized Singleton getInstance() 中的没一个关键字都进行了解释，以及性能问题，三种构造方法都是有不同的场景，而且都有相应的问题，并告诉我们：当你需要它的时候先选择一种合适的使用，如果出现问题，再根据需求进行修改就可以了。