认真思考创建对象的几种方式
序言
周一一不小心又把右侧腕关节给摔伤了，因此这周可能写不了代码了。我就琢磨着构思一片文章，不能把脑袋也停下来。恰好周一早上一位朋友大清早的通过QQ群给我打招呼，于是我就抓住了机会。想从他那里偷点东西用在我的文章上。虽然我又回到了刚练习打字的时代，一个键一个键的戳，但是我们聊的还是很High。聊天的内容有很多，大部分是他在问，我在答。尽管我的答案不能令他满意，但是我还是比较开心的。本来我觉的我们的聊天记录贴上来可能就是一篇文章，可是由于我的聊天习惯，我手贱把聊天记录删除了，因此我写下了这篇文章，尽量的去回忆我们的聊天记录。想了很久，我们聊的最多的就是对象创建的几种方式，下面我先来回忆一下我理解的创建对象的几种方式。
工厂方法模式(Factory Method Pattern)
定义：定义一个创建对象的接口，但由子类决定要实例化的类是那一个。工厂方法让类把实例化推迟到子类。
在工厂方法模式中，核心的工厂类将不再负责产品的创建，而是将创建的工作交给子类去完成。它仅仅负责给出接口，不负责具体实现。因此可以轻易的引入新产品。
控制反转(Inversion of Control)
在没有引入控制反转这个概念之前，当A对象需要B对象的时候，A对象必须主动去实例化B对象或者获取B对象的引用，控制权在A对象自己的手上。在使用了IOC之后，当A对象需要B对象的时候,IOC容器会主动注入一个B对象给A使用，A是被动接受B对象。在A获取B的过程中，获取B对象的方式被反转了。由主动获取变为被动接受，这就是控制反转。
依赖注入(Dependency Injection)
经过查询资料得知，依赖注入这个概念是Martin Fowler提出的。他提出IOC控制反转指的是获取对象的过程被反转了，获取对象的过程由自身主动管理变为IOC容器主动注入。于是他提出依赖注入这个概念。所谓依赖注入，就是IOC容器在运行期间动态的将某种依赖关系注入到对象之中。所以，依赖注入和控制反转是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现具有依赖关系的对象之间的解耦。
服务定位器（Service Locator Pattern）
一开始我并不知道这个模式，我是在构思如何包裹我的IOC容器的时候发现这个模式的。当时我想的是如果我想换一个IOC容器，只需要改一个配制就可以完成IOC容器的切换，摸索中知道了这个模式。这个模式想要解决的问题就是解耦合服务提供者给用户，用户无需直接访问具体的服务提供者类。
区别（what's the difference？）
程序的侵入性：1.调用第三方的API 2.方法参数接受第三方API 3.实现了第三方接口 4.继承了第三方基类
- 从目的角度来看：工厂模式的目的是将实例化推迟到子类，而IOC是为了实现具有依赖关系的对象之间的解耦。因此当我们遇到 new Service(new Repository(new UnitOfWork()) )这种情况的时候，肯定选择IOC，因为无论是什么工厂都是不容易解决这个多层依赖关系的。
- 从对象生命周期角度来看：工厂是无法管理创建对象的生命周期的。对于工作单元来说，每个请求必须在同一个工作单元内，不然是无法保证事务的一致性的。
- 从单元测试的角度看：IOC可以使依赖对象相互独立，可维护性好。每一个对象都可以单独进行单元测试，只要保证自身无误就好。
- 从程序的侵入性角度来看：明显服务定位器违反了第一条，并且使得程序和ServiceLocator增加了耦合，而IOC并没有违反。
综上所述，朋友鼓励我多用依赖注入，不用封装IOC容器。
I could go on,but i think I've made my point!
