软件复用本质是为了快速适应不断变化的需求（adapt to changing needs ），两者目标是一致的，但是当我们过于注重软件复用（如组件复用component reuse又译构件复用）时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文试图阐述两者概念比较以及时下流行的组件复用技术概要。
适应需求变化
现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。 谈到这里，稍微再说明一下国人软件教育的误区，不错，软件曾经是科学计算的工具，因此，我们非常注重软件的算法和数据结构，甚至将之作为数学的衍生物，但是，现如今已经成为一种帮助我们快速响应变化的有力工具，如果我们的教育背景中只有算法和数据结构，能够编制出应付快速变化的软件吗？很显然，他们是风马牛不相及，由此可见国人软件概念和软件教育的落后性，在这样的软件认识背景下，固然设计模式的崇高位置得不到确立，软件设计被抛弃在脑后，编制出的大多数企业软件系统根本不具备应付变化的能力，程序员拒绝频繁更改程序，甚至借助技术原因阻扰软件的频繁更改，这种软件程序员和软件用户之间的矛盾可以称为miscommunication， miscommunication是导致软件系统的失败一个重要原因。 国内早就有著名言论：“不上ERP等死；上了ERP找死”，如果你的企业不上ERP，那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会被淘汰；但是，如果上了一个不注重“适应需求变化”的ERP软件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。 适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢？ 原则：给予人们可以裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。
组件诞生
将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。 让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。 从1970到1980这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASE工具，面向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是最初是通过设计模式实现的。 进入90年代中期，诞生了基于组件的开发模式（CBD：component based development），CBD将抽象概念带往了一个新的方向，与减少代码数量相反，CBD将功能各个方面细化分离到不同的、相互隔离层中，如表现层、业务逻辑层、持久层、安全层以及核心层等，并且可以管理这些组件之间的依赖关系，通过这种分离，我们可以提纯细化组件功能，进而产生可以重用的框架，如Struts框架可以重用在大部分应用系统的表现层中，，Struts+JdonFramework+Hibernate是一个框架组合，代表一种架构设计，这种架构设计其实可以重用在大部分应用系统，这种重用我称之为架构级别重用。
组件复用
软件组件(Software components)是软件提供业务或技术功能的基本单元或元素
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
