序言
周一一不小心又把右侧腕关节给摔伤了,因此这周可能写不了代码了。我就琢磨着构思一片文章,不能把脑袋也停下来。恰好周一早上一位朋友大清早的通过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!
作者:Dynamic-xia
博客地址:http://www.cnblogs.com/dynamic-xia
声明:本博客以学习、研究和分享为主,欢迎转载,但必须在文章页面明显位置给出原文连接。
时间: 2024-10-10 01:03:02