依赖注入真的能够降低耦合吗?

07-09-06 bsglz
         

接触依赖注入有一段时间了,对于它的好处基本上都是这样说:“bean自己不再负责对象的依赖关系,从而降低对象之间的耦合。同时让开发者把精力放在业务逻辑的编写上。”

但我总怀疑是否真的降低了耦合,因为我们在获取想要的bean的时候还是一样的通过一个唯一的标识,对于既有的设计而言,这样做只是把存在耦合的地方汇总起来,方便我们查看更改。

我觉得想要降低耦合,只能通过良好的建模,以及之后的重构。

个人观点,有理解不到位或者错误的地方,请不吝赐教。

         

slangmgh
2007-09-06 12:13

关键是如何理解“耦合”这个词:

Interface bi;

Class b implements bi;

1. Class a 中,Class bi = new b();

a 和 bi是编译时耦合。

a 和 b 之间是编译时耦合。

2. Class a 中,Class bi = Class.forName("b").newInstance();

a 和 b 是运行时耦合,但是只是推迟了耦合的时机,和 1 没有本质区别。

3. Class a 中,Class bi = Class.forName(bname).newInstance();

bname从外部配置文件中或者参数中获取。

a 和 b 是潜在运行时耦合,你可以用类c替换b而不会影响a。

IoC的效果和 3 一样。

对于耦合关系的设计并不是越低越好,也不是越高越好,而是必须将设计中的耦合关系和业务模型中的耦合关系保持一致。

当业务模型中a必须依赖b的时候,最好的设计是1,这个时候代码最清楚、简洁,也最直接的表达出它们之间的耦合关系,如果用3反而使得a无法理解。

当业务模型中a是依赖于bi的某一种实现的时候,最好的设计是3。

注意,在设计过程中,解耦不是目的,让bi的实现可以不影响a而变化(前提是bi的实现确实存在潜在的变化可能)是目的。

使用IoC也一样,不要把所有的依赖关系的分离,这样你的设计将让人无法理解,包括你自己。

bsglz
2007-09-06 12:32

你的例3中“a 和 b 是潜在运行时耦合,你可以用类c替换b而不会影响a。”

我觉得这是面向接口带来的好处,在例1中用new c() 代替 new b()不也是可以的吗,假设c和b都实现了bi接口。

slangmgh
2007-09-06 13:01

>你的例3中“a 和 b 是潜在运行时耦合,你可以用类c替换b而不会影响a。”我觉得这是面向接口带来的好处,

说对了,其实所谓IoC就是接口实现分离的一种使用方式而已(当然不局限于接口,基类也行)。

>在例1中用new c() 代替 new b()不也是可以的吗,假设c和b都实现了bi接口。

如果你愿意修改代码的话,一切都是可能的。

bsglz
2007-09-06 13:53

但是面向接口好象是在代码中实现的,正如你上面的例子,而我们通过name从容器中获取bean的时候还是对应的具体的class。

所以,在我看来,依赖注入所做的只是把代码中需要修改的地方挪到了配置文件中。

7Go 1 2 3 4 ... 7 下一页