巨无霸 对 组件模型

 

基于组件的应用程序结构域与传统的巨无霸程序有着根本的不同。为了理解不同，我们来比较一下相同应用程序的各个实施方法。

 

巨无霸模型

现在，假设你是一个软件公司的产品经理，负责为制造业研发软件。这个软件应用于车间层用于跟踪多种产品，从飞机到瓶盖。这个程序必须能够跟踪制造零件的执行工艺和工程图纸。

软件会储存制造资源信息用于改进生产流程并且会与订单商务系统接口。另外，你的系统还会与车间设备交互，启动和停止设备并处理各种像瓶颈或抛锚一类是的事件。

 

用传统的方法来编写这个软件是创建一个巨无霸程序。这个程序可能有上千行的代码并且需要一个大型全职程序员团队来维护。它可能是由一种语言开发，譬如C++。即使这个程序在某方面用其他语言编码比较方便，你也不会愿意这样做，使用两种以上语言总是会有问题。

 

巨无霸解决方案提供固定功能。换句话说，就是很难根据每个客户的不同需求定制。如果客户不喜欢该系统的某个部分，他们只能是提出需求并且期待在下个版本改变。每个不同的制造商都会需要个性化的实施。每个新客户都需要一个新的开发周期。在这种情况下升级是困难的因为应用程序编译成了一个大的可执行文件。这个巨无霸方案同时也阻止（或者严格限制）第三方扩展或增强。因为所有代码都被编译进了巨无霸，想向编译好的代码增加功能是非常困难的。

 

组件模型

现在考虑使用软件组件实施同样的制造系统。用一种基于自由标准组件的解决方案可提供所需要的功能。例如：部分代码控制车间层的一些设备（譬如包装机）成为独立组件。核心应用程序使用界定清晰的固定行为通信。基于组件的方法有一些先进之处。首先整个应用程序的复杂度降低了。在任何模块中，与其期望代码复杂度以指数方式增加，不如以线性方式增加。开发者使用巨无霸模式，不仅要对他们自己的代码拥有直接的知识，同样对他们想要交互的代码也要有。在巨无霸模式中，一部分代码的小改变可能会对另一部分代码产生重大的边界影响。而当使用基于组件的模式时，每个模块都是独立的。这样，每个程序员所要管理复杂度的仅是他或她正在开发的组件。由于每个组件都是独立的，因此每个组件的内部之间相互不受影响。通过逐个击破技术，应用程序的复杂对就被降低了。

 

因为每个组件都是独立的，所以每个组件都可以使用看起来最合适语言开发。只要组件保持着二进制兼容性，就与语言无关。这就让每个开发者可以选择最好的工作工具。

 

基于组件的方式，为应用程序定制化或增加功能提供了一种方便的途径。例如：如果用户更换了一台新型的打标机，就很容易更换打标组件来适应新机器。只要新组件对旧组件是“插头兼容”的，新组建就能提供所需要的增加功能。此外，新的组件可以不必由应用程序的开发者提供支持。而是可以由出品这个新打标机的公司或者其他第三方提供。这样，应用程序的功能可以使用不受开发者限制的方式修改或扩展。