河里的构件从哪个地恰儿来？

(这个问题琢磨了好几天，越琢磨越觉得是个大问题，都快理解不了了，从朴素的想法开始，然后看了几篇paper，然后彻底就晕了：好大的范围啊。可能看paper，琢磨paper的哥们姐们都有类似的感觉。)
第一个毫无疑问：经验。项目或者产品中反复出现的same job，有必要extracted and generalized into component，借用Refactoring的术语就是Extract Component，这也应当是构件最踏实、最稳妥的诞生方式；第二种就是把构件当作普通软件一样看待了：客户提出需求，根据需求开发，Components-by-Design，Flashline公司的一项业务。还有其他方式么？没了，其他的都可以归为这两类。其实就是bottom-up方式和top-down方式。

1. Extract Component就涉及到构件内部结构问题：如何从一堆class，或者好一些package中Extract出一个足够general的component?

（ 按照费曼的话者应当是一个“显然的问题”。这哥们眼中只有三类问题：显然的，不显然的，费解的；显然的就是任何受过训练的哥们花点儿时间都能搞定；不显然的是搞定了就能得诺贝尔；费解的，呵呵，他说混沌算一个）

那我们看看这个问题有多显然。我琢磨这个是因为看到Agile Software Development，chapter22，Bob说如果包结构不好，也就是H因子（Relational Cohesion，一个表示“包内聚程度”的度量量）太小，D'因子（Normalized Distance from the Main Sequence，表示“包抽象程度和稳定（stability）程度是否平衡”的度量量）也太小，就会导致development environment will be sensitive to change, which may cause unnecessary rerelease and retesting。我第一个念头就是Component is immunity to low-abstraction (H偏小)。不是么？Component需要的、提供的都是通过interface来定义的，那么不就天生programming to interface。但是，是这样么？好像没这么简单。
Clemens说基本上采用一中Component Arch或者Component Framework时候，Component Model就订了，没错，但这是说结构，不是内容，内容哪儿来？一个哥们说One answer is ontologies，一堆Knowledge engineering的东西( where do components come from): You can build an ontology, develop domain architectures and templates from it, and create component-based systems that facilitate the sharing of information based on the ontology.

2.那第二个component by design怎么样呢？TDD这么好，能不能Test-Driven Component Development (TDCD)？后来感觉是扯淡，TDD，模式等东西力量之源就是“模糊”，很像咱们中国古人搞得一套，说不清楚，但是就是好用。形式化不是万能的：XP核心就是不定的重构（你说改也行，但这是有保证的改，不是瞎改，除了莫扎特的音乐，啥不是改出来的）但构件就要形式化，哪一个contractual specified interface得非多少力气去与变化的需求同步去？tools？感觉不是那么好影射的，所以和小董张罗了一阵觉得没戏，就撂下了，原谅我，小董。

最新对构件的认识：这就是比对象好一点儿的东西，或者说白了，就是人们用对象用多了，知道怎么用了：清晰的 explicit的contextual dependencies，接口和实现一定要分析，粒度大点儿，也就是抽象程度高了（是么？那Facade不也是干这个的么）等等，等等，好好看看Agile Dev书和J2EE without EJB后，感觉component就是个新名词，Spring哥们不明白Object和Component本质区别在那儿，还在他的书中（J2EE without EJB）质疑了一把，我觉得有道理——不是墙头草啊！否定之否定吗，不过我准备把这个问题扔给Clemens老兄，看他怎么回答，呵呵，期待啊！（谢谢他老哥们，那么忙还顾得上回复我的弱问题，交情啊）

所以，总结是，不需要Component，好好用Object就够了（看以后会不会再变？）对了，Spring中的bean就是POJO，那XML定义的组合不就是构件组合模型么？以我一个老构件工作者的眼光就要大喊：我靠，构件吗！

最近在乖乖的看component-based os方面的文章，回头好好说说OS中的构件是个啥样，先预报一句：It's really a big surprise!