- 定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立的部署并由第三方任意组装。
- 定义2：构件是系统中有价值的，几乎独立的，且可替换的一个部分。它在良好定义的体系结构语境内满足某清晰的功能。
- 定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
构件和传统的对象比较，我们一般认为构件的粒度比对象要大，服务又比构件要大一号。而构件和对象具体有如下一些区别:
构件的特性 | 对象的特性 | 模块的特性 |
独立的部署单元 2.作为第三方的组装单元 3.没有（外部的）可见状态 | 一个实例单元，具有唯一的标识 2.可能具有状态，此状态外部可见 3.封装了自己的状态和行为 | 结构化开发的产物 |
没有外部的可见状态就是，直接从外部不能访问，一般提供统一访问的入口。对象如果没有封装好的话，外部是可以访问的，如果封装好的话，也能做到统一入口访问，这样安全性和可靠性会更高。
构件系统架构的特性(了解,不怎么重要)
构件系统体系结构由一组平台决策，一组构件框架和构件框架之间的互操作设计组成。
构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定的作用于构件层次机制的策略。 概念框架的互操作设计包括系统体系结构连接的所有框架的互操作的规则。
构件是一组通常需要同时部署的原子构件，构件和原子构件之间的区别在于，大多数原子构件永远不会单独被部署，尽管它们可以被单独部署。
一个原子构件是一个模块和一组资源。模块是一组类和可能的非面向对象的结构体，比如过程或者函数。资源是一个类型化的项的固定集合。
资源可以包含代码，进而包含模块，问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在纯对象的方法中，资源是外部化的不可改变的对象。不可改变是因为构件没有持久化标志，而且赋值不能被区分
构件的复用
假设我们要利用构件的思想开发一套系统,首先我们要经历这样一个流程：检索于提取构件--->理解于评价构件--->修改构件--->组装构件.
检索于提取构件
- 检索于提取构件
一般是已经有了一些构件,但是标准化程度不是很高,此时需要先去找到构件
然后把构件提取出来
检索和提取构件有几种方式
- 基于关键字的检索
系统在图形用户界面上将构件库的关键字呈树形结构直观的展示给用户,复用者通过对树形结构的逐级浏览,寻找需要的关键字并提取相应的构件.
- 刻面检索法
该方法基于刻面分类法,由三步构成,分别是构造查询,检索构件和对构件进行排序.优点是易于查找相似构件,但构造查询时比较麻烦.
- 超文本检索法
复用者先给出一个或多个关键字,系统在构件的说明文档中进行精确或模糊的匹配,匹配成功够列出相应构件说明. 优点是对用户友好,但有时候难以在浏览过程中找到正确的那部分构件.
提取构件之后,需要理解和评价构件
理解于评价构件
检索于提取构件--->理解于评价构件--->修改构件--->组装构件.
- 理解于评价构件
要复用构件,准确的理解构件是至关重要的.特别是您要使用或修改这个构件时.
为达到目的,必须要求构件的开发遵循公共标准
一般构件库的文档中全面而准确的说明了构件的功能与行为,相关的领域知识,可适应性约束条件和例外情形,可预见的修改部分及修改方法.
当您理解这个构件是怎么一回事了,它能不能达到我们的要求,是不是完全匹配我们的需求, 假设这个构件不能完全满足需求,有些功能有,有些没有，此时就需要修改构件了.
修改构件
检索于提取构件*--->理解于评价构件--->修改构件--->组装构件.
- 修改构件
理想状态是直接复用现成的构件,但多数情况下,都必须对构件进行或多或少的修改,以应对新需求.
为了减少构件的修改工作量,要求开发人员尽量使构件的功能,行为和接口设计更加抽象化,通用化和参数化.这样,复用者可通过参数选取来调整构件的功能或行为.如果仍不满足需求,必须借助设计信息和文档来修改构件.
构件库中若无可修改使用的构件,则按新需求开发构件,并存入构件库.
当所有的构件都开发或修改完成之后,我们就可以把构件组装起来,完成我们的需求.
组装构件
检索于提取构件*--->理解于评价构件--->修改构件--->组装构件.
- 组装构建
基于功能的组装技术
基于功能的组装技术采用子程序调用和参数传递的方式将构件组装起来.就是我们模块于模块之间的调用于组装.
基于数据的组装技术
- 根据当前软件问题的核心数据结构设计出一个框架,然后根据框架中各个节点的需求提取构件并进行适应性修改,再将构件逐个分配至框架中的适当位置.后面,组装方式仍然跟传统方式一样，也就是子程序调用于参数传递.
面向对象的组装技术
- 由于封装和继承的特性,面向对象方法比其他软件开发方法更适合支持软件复用.如果满足需求,直接复用,如果不满足,必须以基类作为父类,生成对应的子类,以满足新系统的需求.
而在组装过程中有可能会存在一些失配的问题，包括如下一些问题：
- 由构建引起的失配，包括由于系统对构件基础设施，构件控制模型和构件数据模型的假设存在冲突引起的失配。
- 由连接子引起的失配，包括由于系统对构件交互协议，连接子数据模型的假设存在冲突引起的失配
- 由系统成分对全局体系结构的假设存在冲突引起的失配等。
要解决失配问题，首先要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
小结
构件的一些基本概念就大概这些，这些概念我们还是要结合实际情况去理解它，不然这么枯燥的知识海洋，当我们时刻都用蛮力去遨游时，总会有精疲力竭之时。 学无止境，加油！
