IOC模式的思考和疑问

05-11-11 cats_tiger
              

IOC,是现在很火的设计模式,就像当年的Factory和Singleton模式一样。IOC模式为我们提供了真正(?)的松散耦合,但是松散耦合真的这么酷吗?紧耦合真的一无是处吗?不见得。
首先,使用IOC模式就必然会依赖于一些IOC容器,除非你直接使用反射(-_-),比如Spring,这对于勾结的独立性是不利的,试想,如果每次使用java.lang.String的时候都必须import org.springframework…。对于一些要求响应速度的系统而言,IOC的使用必然会降低系统性能(new 的速度肯定比Class.forName块),缓存?忘记它吧,我已经强调响应速度了。再说,IOC跟缓存和池没有必然联系呀。
其次,IOC模式的大量使用会降低一些复杂模块的可读性,要知道,如果你不能写出很好的文档(多数人都是如此),那么代码就是你唯一可以与其他人沟通的语言。如果阅读代码的人不懂IOC,不会使用Spring呢,他如何理解你那些接口的实现?
第三,IOC容器的大量使用会造成额外的维护成本,很显然,你现在不仅仅需要维护你的代码,还需要维护你的applectionContext.xml,如果是WEB应用,则需要注意维护哪些Context-Param。尤其是,虽然代码中不存在耦合关系,但是耦合关系都在配置文件中,你在写出松散耦合的代码的同时也必须去写紧耦合的配置文件,对于一个大型系统而言,大量的配置文件的管理本身就必须付出高昂的代价。
最后,我认为真正意义上的松耦合是不存在的――是的,你可以“依赖”接口编程――但是毕竟还是“依赖”了。既然没有绝对的松散耦合,那么我们是否可以考虑在一定范围内使用紧耦合呢?ArrayList和Collection是紧耦合,你是否觉得不便呢,ArrayList和Iterator更是紧耦合,难道Iterator不好用吗?
考虑一下传统的工厂模式吧,它在一定程度上体现了IOC的思想,但是又没有完全的实现IOC。你可以使用工厂模式实现接口编程,但是依赖关系仍然需要在代码中体现。Hibernate是公认的优秀产品,它没有使用IOC,大量的Factory充斥其中,但是Hiberante的质量和升级速度有目共睹。也许你会说,IOC容器提供了很多底层的东西,例如缓存和对象生命周期管理等,以Spring为例,缓存倒是有,可是生命周期管理就不见得,事务管理还是需要客户介入。再说了,这些都是容器提供的,IOC模式并没有要求。之所以谈这些,主要是考虑实现一个带有缓存和“挂钩点”的工厂,这个工厂提供对象的创建和pool&cache管理但是不提供依赖关系管理。
那么IOC这个模式在哪里使用呢,我认为,应该在构件这个级别使用。构件应该是一个封装的很好的模块,它提供独立的、具有实际意义的功能。通过对构件的粒度的设计控制IOC使用的密度。而构件的内部,可以使用传统的工厂模式,也可以什么模式都不用^_^。只要提供清晰准确的接口,并且封装接口在构件内部的实现,那么即使使用public变量都没有关系!

              

7
鲁中正气
2005-11-11 09:39

>那么IOC这个模式在哪里使用呢,我认为,应该在构件这个级别使用。构件应
>该是一个封装的很好的模块,它提供独立的、具有实际意义的功能。通过对构>件的粒度的设计控制IOC使用的密度。

我也深有感触,同意,同意。

如果粒度细了当然也可以,不过这时候我们就应该有图形化的配置工具来管理这些xml文件,能让他和类一起自动产生,就好了。
目前,这种工具的工具做的还不好,以后会发展起来。这应该是趋势。
谁把这个做好了,谁就能雄起吧~~

banq
2005-11-11 10:26

cats_tiger提出的疑问只是从Spring这个产品来看,Ioc模式和Ioc容器是有区别的。

>写出松散耦合的代码的同时也必须去写紧耦合的配置文件
这是Spring的缺憾,你看看Jdon框架的配置是否属于紧耦合,这里面autowiring很重要,HiveMind的配置也非紧耦合。

我一再强调Pico/Jdon HiveMind的IOC模式实现要比Spring好多,可以多看看这些,有时不是商业炒作得厉害就是好东西。

理解Ioc模式要从一个高度来看,不能局限于某个产品。

另外,cats_tiger的观点"IOC这个模式在哪里使用呢,我认为,应该在构件这个级别使用"是正确的。

不过,我一直认为构件就是组件,Ioc容器本来就是进行组件(构件)管理的容器,这方面是专长。将component翻译成构件,我认为组件更准确。我们不能因为别人提出一些新名词,而以为是一个新概念。

cats_tiger
2005-11-11 10:46

组件和构件俺从来就没有区分过他们,好像是滑鼠和鼠标之间的区别。Jdon框架俺也看过,虽然看的不深入但是感觉确实不错,但是从配置文件的角度考虑,也是比较麻烦的,Banq是作者当然觉得简单。另外,无论是Spring还是Jdon或者Pico,IOC的使用都是灵活的,可以在构件(原谅我仍然使用这个词)内部也可以在构件之外。我的观点是构件内部使用GOF的设计模式,并通过接口向外界提供服务。构件和构件之间可以使用IOC模式以体现松散耦合的特性。
另外,单从IOC容器的角度考虑,我是真喜欢轻巧的PicoContainer,可是Spring提供的各种小工具和模板确实好用,我更喜欢。

MiMiEye
2005-11-11 11:15

前两天还见到有人提出现在不是代码编程的时代,而是配置编程的时代。同感啊。

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