依赖注入与抽象工厂模式，有什么区别。。。

RUNBEAR 2011-07-11 05:54:33

如题。。不是都是由反射建立一个实例吗。

...全文

1194 28 打赏收藏转发到动态举报

写回复

用AI写文章

28 条回复

切换为时间正序

请发表友善的回复…

发表回复

lf_net 2012-10-11

打赏
举报

好强大的解释阵容...

以专业开发人员为伍 2011-11-22

打赏
举报

这就好比说有说“软件开发不就是0、1、或者就是汇编嘛。高级语言没有一点心新意。我想对于那些不讲模式的人，这是对的。而且这种人都认为越是低级的东西越“高效”，这对于他们来说也是“对的”。

其实就是你有没有自己的分析和规则。我看不出你自己的内涵，我就不知道跟你分析什么。如果只是说它们哪一个流派曾经更时髦，这对于你其实也许对你的真正去做出许多好的项目并没有非常大的帮助。他们主要都是学术上的时髦、契合了java（而不是.net）的自由开源精神所以一大堆大学教授（而不是企业里的的程序主管）非常喜欢在课堂上、社区里不断引用这类著作而已。

以专业开发人员为伍 2011-11-22

打赏
举报

“四人帮”说模式有23种，后来AOP论证说明其实百分之85%以上的所谓模式都是空洞的、都可以用一个AOP概念轻松地替代。这就是AOP的初衷。

当然AOP也有很多想不到的地方。但是这属于狗咬狗，都是过时了10几年的东西。其中AOP现在看起来非常混乱，你想一个万能地修改源代码的东西，你还如何维护它？！

daniel_chen12 2011-11-22

打赏
举报

工厂类在实例化类时调用该类的setXXX（）方法将一些该类需要的参数
（即该类不知道工厂类的存在）
这种方式约= 依赖注入

windowslinuxjavanet 2011-07-20

打赏
举报

spring.net就有ioc依赖注入,
工厂模式常用在多个数据库的情况下
有兴趣可以加入.net开源交流群共同讨论学习 69594961

confidenceyu 2011-07-19

打赏
举报

up，学习

jiangshun 2011-07-19

打赏
举报

一个是原则一个是模式

indusl 2011-07-19

打赏
举报

好晦涩，留有慢慢理解

weike021996 2011-07-19

打赏
举报

好晦涩，留有慢慢理解

一片冰心在玉壶 2011-07-19

打赏
举报

新人混脸熟膜拜学习

cento123 2011-07-19

打赏
举报

[Quote=引用 11 楼 runbear 的回复:]
引用 5 楼 cento123 的回复:

工厂模式的类是这样写的：
C# code

class Obj : IObj{
private IPropObj mPropObj=null;

//构造函数
public Obj(){
mPropObj=Factory.CreatObj<IPropObj>();
}
}

你这写，区别在于，一个是客户类通过方法或者构造函数,……
[/Quote]
依赖注入、工厂分别是两个框架。
你写的类是哪个框架下的，就应该用对应的写法写类。

依赖注入的框架创建对象时（创建Obj时），会自动找到类的注入法SetPropObj（或者类构造函数中接口定义参数－－构造注入法），创建对应的对象（IPropObj的实现类），这样你的程序中任何地方都找不到创建IPropObj的地方，只会在框架的配置文件中找到IPropObj是用哪个实现类－－你想改用另一个实现类，就要在配置文件中修改。

工厂模式下，那个Factory是工厂框架的对象，如果你要改换IPropObj的实现类，那个就应该改工厂的配置文件中IPropObj的定义，或者框架指定的定义地方（你在那里可以看到IPropObj是怎样创建的）。

在类的实现类会有多个的可能（如不同的客户PropObj的实现不一样），并且常要改动时（客户C与客户A用的是PropObjA，客户B用的是PropObjB）时，mPropObj=new PropObj()的类创建方法就很难搞了！

RUNBEAR 2011-07-12

打赏
举报

[Quote=引用 5 楼 cento123 的回复:]

工厂模式的类是这样写的：
C# code

class Obj : IObj{
private IPropObj mPropObj=null;

//构造函数
public Obj(){
mPropObj=Factory.CreatObj<IPropObj>();
}
}
[/Quote]
你这写，区别在于，一个是客户类通过方法或者构造函数,主动设置服务类，赋予字段？

RUNBEAR 2011-07-12

打赏
举报

[Quote=引用 3 楼 sandy945 的回复:]

从结果上来看是这样的。但思想的跨度不是代码的差异所能体现的。

容器这个概念是很重要的

就举主板的例子吧，这里主板就是容器

先说抽象工厂

CPU想访问硬盘它所知的硬盘位置是固定的，CPU依赖于 IDE接口来访问硬盘，假若硬盘挂了的话，CPU就访问不了了。因为IDE接口已经定死了，是变动不了的。

而依赖注入

则由容器来完成相关调度, 就是主板，CPU想访问硬盘……
[/Quote]
您说的这些，能不能理解为程序集的概念。通过配置文件，指定调用的程序集名称，不是没有定死了吗？
有点不懂。。。。

truecoffeefox 2011-07-12

打赏
举报

[Quote=引用 10 楼 runbear 的回复:]

引用 3 楼 sandy945 的回复:

从结果上来看是这样的。但思想的跨度不是代码的差异所能体现的。

容器这个概念是很重要的

就举主板的例子吧，这里主板就是容器

先说抽象工厂

CPU想访问硬盘它所知的硬盘位置是固定的，CPU依赖于 IDE接口来访问硬盘，假若硬盘挂了的话，CPU就访问不了了。因为IDE接口已经定死了，是变动不了的。

而依赖注入

则由……
[/Quote]
你还没看明白，依赖注入并不需要知道最终用的是那个，至于用到的那个是由容器来决定

阿非 2011-07-12

打赏
举报

先说依赖注入与抽象工厂模式的共性

针对接口编程，不针对实现编程。间接的就符合了LSP和Design by Contract理论，实现功能上符合了ISP。

区别在于

抽象工厂模式只是部分满足了DIP，因为它未满足“高层模块不应该依赖于低层模块，二者都应该依赖于抽象”,换言之在相关高层模块还有抽象工厂的存在，就是依然存在耦合。解耦是最终目的，但实际情况是不可能消除耦合。但IoC or DI 这个思想借鉴了硬件设计，将耦合转移了从而变相的讲模块之间的耦合消除了，将模块之间的耦合转移到了模块与容器之间。从而IoC or DI完全满足了DIP

===================================================================================

CPU想访问硬盘它所知的硬盘位置是固定的，CPU依赖于IDE接口来访问硬盘，假若硬盘挂了的话，CPU就访问不了了。因为IDE接口已经定死了，是变动不了的。
------------------------------------------------------------------------------
这段描述中说明了一些问题，就是“CPU依赖于IDE接口来访问硬盘”说明了耦合的存在，CPU在设计时必须要
设计访问硬盘的途径，eg: IDE接口，虽然它不关心访问的是ATA还是SATA。

另一种情况，借助主板。 CPU只需发送一个指令，剩下的只是等待。会由系统总线中的地址总线AB和数据总线DB等协同工作，并将结果返回。

RUNBEAR 2011-07-12

打赏
举报

自己顶一下。

RUNBEAR 2011-07-12

打赏
举报

1.用接口就起到能契约和统一标准了。
2.降低耦合，不需要在两层里面实例化对象。
但第三点，我就不清楚。

--缪军-- 2011-07-12

打赏
举报

一个有经验的设计师,每当碰到稍微复杂的问题,
就会自然而然的想到引入一个虚拟的组件来辅助解决问题
而这个虚拟的组件可能起到这些作用:
1.契约,统一标准;(楼主所说2种情况的都是侧重实现这一效果)
2.隔离,代理;
3.控制,转换;

现在的技术条件,使得我们可以用更直白的,更统一的方法论来解决问题