pico印象

to ajoo:
对于第一问题，感觉很奇怪，没有找到对应代码，不好多说。但感觉上不应该出现这种情况。
第二个问题，我没有用过life-cycle这样的接口，只是简单的利用spring中的init-method而已。这个就推荐你看exo的源码了，它里面有很多代码都继承了life-cycle的接口。

第一个问题，你可以看它的网站：
http://www.picocontainer.org/Implementation+hiding+and+Hot+swapping

看看是不是我哪里看错了。

第二个问题，
感觉上，spring的init_method, destroy-method的方式明显比pico的Startable, Stoppable灵活，侵入性也小。

不过，对spring的这个东西的语义有点疑问。

1。这个init_method在什么时机调用？不应该对使用者透明吧？
destroy-method又什么时候调用呢？
这个时机可以编程控制吗？
（我估计仔细看spring的源码是可以找到答案的，不过懒一下，看看是否可以有巨人的肩膀踩一下 ）

2。对异常如何处理？
如果spring容器在对组件调用init的过程中出现异常，是下面三种中的哪一种？
  a. 直接抛出异常。
  b. 对已经init过的组件undo（调用destroy-method），然后抛出异常。
  c. 忽略，继续初始化后面的组件。
如果spring在调用destroy的过程中出现异常又如何？

pico的代码只采用第一种直接抛出异常的方法。个人觉得这至少对dispose的语义来说不合适。我们一般编程都知道，在finally语句块里面，即使某一个close()失败了，也应该继续清理其它的资源的。再次鄙视一下pico。

没有看见实现代码,但看文档中的代码,觉得有点难受,因为自己设计Man的时候没有实现Swappable接口,但忽然在实际应用中:

((Swappable);woman.getMan(););.hotswap(superman);;

有点不可接受.宁愿用你的方式完成.看看它的具体实现代码也许能找到非此不可的原因.


其实spring也有InitializingBean/DisposableBean,但spring在文档中也说不建议使用这两个接口,而是使用init-method/destroy-method标示.对于初始化方法应该是在创建后就会被调用.spring的文档中3.4.1. Lifecycle interfaces仔细介绍了这些内容.


spring应该也是这么处理的,我理解容器对于init发生错误,就认为是一个无法挽回的错误,直接停住了.而对于destroy应该属于收尾工作了,能不管就不管了.
至于象ejb容器,某个ejb组件的失败,并不影响其他ejb组件这样的功能比较难实现,而真正的需求又不是太高吧.

如果init的时候打开了某些文件（或者拨了一个国际长途电话之类的），真的能就不管了？



同样，即使某个组件清理失败，别的组件也不需要清理了？文件和数据库连接不关了？ 守护线程不结束掉？

对于初始化失败,是整个应用都停掉了,而不是某个组件停掉.
对于清理,倒应该是单个组件的失败不应该影响其他组件的销毁.

还是继续说pico吧。

((Swappable);instance);.hotswap(abc);;

Components.setProxyImplementation(instance, abc);;

quote]

那个里面的abc是什么用途？

我的看法是，他用了一个统一接口可以更好地在容器层面上组装和切换，而用静态方法不好再接口上进行控制，而做不到更大的共同性和扩展性。

我视觉的动态切换这种东西还是用Interface+IoC控制比较好，不过还是有一定的侵入性，不过算是比较小的，毕竟要规范一个咚咚出来实施

完整代码是:

Object abc = createMyOtherImplementation();;
((Swappable);instance);.swap(abc);;

abc是我另外创建的一个实例，准备偷偷通过容器塞到某一个被代理的组件上。


关于这么做的问题，我觉得不是说舒服不舒服，什么“共通性”，“扩展性“。
问题就在于我开始说的：二义性。
也就是说，这不是一个主观的审美问题，而是客观上的硬伤。


接着说pico。

越看代码越气。什么呀！
想要灵活性，只能自己实现ComponentAdapter，（基本上等于自己砍柴烧火）。想要利用pico提供的功能？对不起，那就别要求东要求西的。

pico的问题在于，除了它提供的do-it-yourself的option外，基本上不灵活，很难扩展。
看看那个Parameter的设计吧。逻辑死板，if-else一大堆。
auto-wring连static method都支持不了。
lifecycle只支持start,stop,dispose。而且支持是直接硬编码进核心代码中，意味着如果想提供额外的lifecycle，就要改动核心代码。
手工配置功能弱，达不到spring的灵活性。

种种种种，差劲啊。当然，也许是现在可以下载的版本还很不完善。不过从设计结构上看，要好也难。

他的lifecycle的确有很强的侵入性,使用者的代码必须要进行修改才能达到。我常用的方法是写了中间一层代码来隔离底层的LifeCycle维护。
这是有别于Spring一种解决方法，因为Spring把这些东西写在XML里面也是需要一些额外工作的，Pico除了弱了一些外，只是把配置之类的东西写在代码里，相对来说我觉得Pico更好重构和处理。

这两种方案是不能拿表现形式来做比较。功能上不可否认，肯定Spring强很多，而且整体性来说还是Spring好些。

Pico毕竟是个Micro Kernel的冬冬呛，Scope就有别于Spring地

从使用者的角度看：
1。lifecycle有侵入性。
2。稍微灵活一点的功能就要自己写ComponentAdapter这个肥得要命的接口。这直接造成代码重用程度差。

从设计的角度看：
lifecycle是直接硬编码进核心，而不是可扩展的以插件的方式提供。
一些核心类，如Parameter，设计死板，扩展性差，实现也不优雅。

其实如果暂时不好用，只要结构好，还可以逐渐扩充，象eclipse那样。
但是，pico这个地基打的这样，注定它永远只能做一个功能弱的kernel了。

我对可扩展性和简单性最重视，你micro没关系，但是要是硬邦邦地只能这么micro，嘿嘿，完蛋了。