构件技术 Vs 构件市场

从来没有一项技术象构件这样和市场息息相关了，构件的特点竟然和市场是如此的interplay。慢慢说。
从构件“前世”——面向对象说起（其实构件和对象是两个如此不同的技术，而构件的提出如果不说比对象早（而Simula67比68年Dijkstra的结果化编成早，programming的发展真是螺旋又messy），也差不多：McIlroy,M.D.,1968. Mass-Produced Software Components提出软件IC。然后构件等了三十年：Cox, B.J.1990. Planning the Software Industrial Revolution. IEEE Software 7(6)）。
面向对象，技术和市场是两张皮。决不是小看OO：单知道了类型、封装、类型继承和多态，你试试去写OO程序，笑死人了，看完（并且练习完）Refactoring, Refactoring to Patterns, Design Patterns才明白什么是OO，这两个圈意味着SRP，OCP，LSP，DIP和ISP等等principle，可不是那么容易做到。
但是不幸OO不是所向披靡的银弹，不足是先天的：implicit arch, implicit reuse contract, missing plugs（大牛Oscar Nierstrasz说的），第一个针对所有OO code，二针对OO的重用单元：OO Framework，三针对OO的分析和设计方法：一，oo code不反映run-time arch（原因恰恰就是力量的源泉：polymorhpism），难理解就难evolve；二，oo framework“罪恶”的白盒subclassing reuse和不明确的reuse contract；三，OOAD鼓励对领域对象进行细致深刻的建模，结果是大量领域、应用相关的interface——which are not plug compatible。基本上OO的全部被攻击了。其实还有第四个：OO软件的质量靠啥？终于明白靠的是不断的refactoring和reengineering，和作文越改越好，面条炒三遍给肉都不换一个道理，而这些刚刚随着agile旋风被业界接受。

构件生而为卖（给内部或外部），为reuse，为提高抽象层次：构件提供的服务应该是难以自己实现，或者自己实现不经济的，构件不能是个Stack，构件至少是个计算器，spell check，是个嵌入式数据库更好。这样一来，一个石破天惊的implication：用构件不是此地new一个就完了，而是做好了等着被拿到好多地方（构件开发者想得到的和想不到的）去组合。要是没人要你，generalize的劲儿就都白费了。构件能否存活和dev app based on component息息相关。一个保守的方法就是“Extract Component”，类比于Refactoring中的Extract Method和Extract Class：发现一个function被用到第三次了，Extract it做成一个构件，自己用，也可以卖给同行业的。
构件依赖于市场。对象技术中没想着组合，没有独立部署，late composition，对象就是一锤子买卖，对象就是用来造monolithic巨兽应用的。
对象忽视了市场，所以“object market”从来就没出现过。
这是技术对市场的作用。

都说构件好，好在哪儿？好在组合。能组合才有市场，所以Oscar说改叫Composition-Based Software Development好了。但是要想能组合，先要解决一堆问题：

1. 能组合的比不能组合的开发代价大。大在哪儿？确保Safety上。测试？组合爆炸：late composition是优点，但也就业味着没有final integration test，传统软件过程的集成测试为组合错误留有余地。这本质上是如何reuse的问题：intentional reuse还是accidental reuse。能做的也只能是选择合适的语言和工具保证modular checking：仅基于所依赖的构件和接口确保自己的safety。何谓safety，就是not do evil：构件自己挂了的时候别把整个系统拉下水。都是组合惹的祸。
   
2. 维护组合起来的系统代价更大。构件独立evolve是优点，但是带来版本兼容问题；寻找和匹配构件呢？（垃圾分类都不容易）构件不是严丝合缝符合，需要优雅的退化时，多接口后面的state关联如何处理？（MSRA面/灭我的时候问的）Adaptor容易么？都不容易

这是市场对技术的反作用。

组合。构件技术研究的问题、难点、和市场的关系，全是围绕着组合。就算解决了Safety和构件系统能工作，还有两点难处，当然，也是组合引起的：

1. 功能。各个构件组合起来的的功能 >= 所需要的功能么，不互相影响么？这个问题OMG都没搞定：它的object service mixing recommendation说能达到正交和互操作（orthogonality and interoperbility），立刻就有哥们叫板：Wallace, Wallnau. A situation evaluation of the OMG's OMA，OOPSLA'96
2. 性能。这才是真正的formidable problem。各个构件有自己的资源需求和消耗约定，组合在一起，整个系统的资源够用不？你怎么知道？CPU，一二级存储，网络，etc

难哪。构件要是自己造，自己用（就是产品线了），好多问题都不存在了，构件也就不能“独立开发，第三方组合、部署了”。
构件市场也就不存在了。