banq
2005-11-11 11:19

>构件内部使用GOF的设计模式,并通过接口向外界提供服务。构件和构件之间可以使用IOC模式以体现松散耦合的特性。

是这样,这实际是一个Ioc模式使用的粒度问题,粒度越细,凡是每个类都使用Ioc模式,都使用Ioc容器配置文件来配置,就麻烦了,最后是一个一个功能服务为主或为模块使用Ioc,就是你说的构件之间使用Ioc模式。

不过:Ioc模式和GOF模式中的工厂模式还是可以结合在一起使用,这样用Ioc模式来提升工厂模式的灵活都和可配置性,这种结合就象以前class.forName和工厂模式结合使用一样。

banq
2005-11-11 11:50

还有一点:使用Ioc模式进行编程,实际是走上一个全新的编程模式,如果说传统编程习惯的人还可以凑合使用Java编程,那么当他遇到Ioc模式编程时,会非常不习惯,会产生一种割裂感。

但是 Ioc已经深入到JSF/Tapestry表现层 组件层甚至持久层时,一种全新的时期到来了,这如同翻上一座高山,看到新的一片美景,以后的技术发展会完全基于Ioc向前发展,有些人预期Java会灭亡,不错,Java语言已经在我们Ioc这座山的脚下了。

以前我说是否会GoF设计模式是衡量一个程序员是否OO的标准之一,那么现在是否Ioc,是衡量一个程序员是否进入现代编程的标准之一。

cats_tiger
2005-11-11 12:18

>使用Ioc模式进行编程,实际是走上一个全新的编程模式。

Banq对新技术的敏感程度令人佩服。但是我并没有感觉到IOC如此重要性和和“全新”特性。很早以前就有“依赖倒转原则”和“面向抽象编程”了,这应该是IOC的前身吧?

IOC就是通往“松散耦合”这个终极目标的一个途径而已。而松散耦合也是有限度的,就好像不能每个类都IOC,也不能离开IOC容器就统统使用Class.forName。之需要保证“构件内部的变化不会被外部感知”即可,这就是松耦合。至于构件内部,我甚至提倡使用public字段替代set/get,多方便呀,只要限制构件外部不能使用即可。这种情况下,IOC根本无从谈起。

yuxie
2005-12-12 16:16

>1使用IOC模式就必然会依赖于一些IOC容器

实际上,良好的设计可以将这些依赖转移到一个配置文件中。对于web应用而言,这根本不是问题,只要你用流行的mvc框架,你的代码压根就不需要出现import org.springframework……。其他的情况,对于api的引用只需要在系统启动的时候import一下就可以了。

>对于一些要求响应速度的系统而言,IOC的使用必然会降低系统性能

这个说法没有意义。

>其次,IOC模式的大量使用会降低一些复杂模块的可读性,要知道,如果你不能写出很好的文档(多数人都是如此),

大部分的情况只要你的接口上有注释说明一下就可以明白了。如果这都做不到,干嘛要用OO的java来做?

>第三,IOC容器的大量使用会造成额外的维护成本,

这也应该是楼主自己想的,俺们从来没遇到过这种情况

>那么IOC这个模式在哪里使用呢,我认为,应该在构件这个级别使用。构件应该是一个封装的很好的模块,它提供独立的、具有实际意义的功能。通过对构件的粒度的设计控制IOC使用的密度。而构件的内部,可以使用传统的工厂模式,也可以什么模式都不用^_^。只要提供清晰准确的接口,并且封装接口在构件内部的实现,那么即使使用public变量都没有关系!

偶觉得这一点说的倒是也没错。不过用了ioc也不什么时间啊~为啥不用呢

yuxie
2005-12-12 16:18

> 还有一点:使用Ioc模式进行编程,实际是走上一个全新的编?> 模式,如果说传统编程习惯的人还可以凑合使用Java编程,那

> 吹彼龅Ioc模式编程时,会非常不习惯,会产生一种割裂感

> ?>

> 但是 Ioc已经深入到JSF/Tapestry表现层

> 组件层甚至持久层时,一种全新的时期到来了,这如同翻上一

> 呱剑吹叫碌囊黄谰埃院蟮募际醴⒄够嵬耆Ioc向

> 胺⒄梗行┤嗽てJava会灭亡,不错,Java语言已经在我们I

> c这座山的脚下了。

>

> 以前我说是否会GoF设计模式是衡量一个程序员欠OO的标准?> 一,那么现在是否Ioc,是衡量一个程序员是否进入现代编程?> 标准之一。

哈哈,偶一前跟一个c++程序员吹嘘ioc时,被笑了一通,人家这不是编程的基本原则吗?有啥好说的。

现在轮到banq被笑话了