面向组件和面向对象编程的比较资料.docVIP

面向组件和面向对象编程的比较 Component-Oriented Versus Object-Oriented Programming 如果任何.NET类都是组件，而类和组件存在如此多的共性，那么传统的面向对象编程和面向组件编程的区别到底何在？简而言之，面向对象编程着眼于被组合到一个大的二进制可执行程序的类之间的关系，而面向组件编程着眼于独立工作的可替换的代码模块，并且无须非常熟悉其内部工作原理。 构建块和单一应用程序的比较 Building Blocks Versus Monolithic Applications 两种方法论的根本区别在于对目标应用程序的关注点。在传统的面向对象世界里，即便你可以将业务逻辑分解到多个细粒度的类中，一旦这些类被编译，最终结果依旧是一个不可拆分的二进制代码。所有的类共享同一物理部署单元（通常是EXE）、进程、地址空间和安全限制等。假如多个开发人员在同一个代码库上工作，他们就不得不共享源文件。 在这样的程序中，对一个类的微小改动都可能导致整个应用程序的重新链接和必不可少的重新测试，同时也包括所有其他类的重新部署。 另一方面，一个面向组件的应用程序包含的是一组相关联的二进制应用程序模块的集合，就是说，一堆组件以及将这些组件关联起来的一堆调用（见图1-2）。 图1-2：面向组件的应用程序 一个特定的二进制组件自身不会做太多的事情。有些是通用组件，诸如文件访问或通信包装组件，有些是高度定制的和专门为该应用程序开发的组件。一个应用程序通过“粘合”一组单独组件提供的功能，从而实现并执行要求的业务逻辑。组件实现技术如COM、J2EE、CORBA和.NET提供了用以无缝地连接二进制组件的“管道”或者叫基础架构，这些技术的主要区别在于允许你连接这些组件的难易程度不同罢了。 将单一的应用程序分解成多个二进制组件的初衷有点类似于将不同的类放在不同的文件中。通过将一个应用程序的每个类代码放到各自的文件中，你可以降低类和负责他们开发的开发人员之间的耦合程度。假如你改变了一个类，尽管你不得不重新链接整个应用程序，但是你要做的只是重新编译那个类的源文件而已。 但是，面向组件编程的优势远不限于简化软件项目管理。因为一个面向组件的应用程序是一个二进制构建块集合，你可以将组件看成“乐高（LEGO）积木”，可以随意地添加和删除它们，直至符合你的要求。假如你要修改一个组件的实现，改变的只是包含在其中的组件而已，不存在组件的客户端要重新编译和重新部署的问题。只要组件不是正在被使用，你甚至可以在客户端应用程序运行过程中更新组件。任何对组件的改进、增强和修复都能够马上提供给所有使用组件的应用程序，不管该程序是在同一台机器上还是在网络上。 另外，一个面向组件的应用程序更加容易扩展。当你要实现新的需求时，就可以在新的组件中实现它们，而无须改动跟新需求无关的现有组件。 上述这些因素使得面向组件编程能够降低长期维护成本，而这一因素对几乎所有组织都是十分关键的，这恰好解释了组件技术能够被广泛采纳的原因。 面向组件应用程序通常能够比较快速地推向市场，因为你能够从一堆可用组件中选择。有些组件来自内部团队的收集，有些组件来自第三方组件提供商，如此一来就避免了不必要的重复开发。例如，许多Visual Basic项目之所以能够做到实现快速开发，就是因为几乎在应用程序的任何方面都可以找到相对应的ActiveX控件类库。 接口和继承 Interfaces Versus Inheritance 面向组件和面向对象应用程序的另外一个重要差别是在继承和重用模型上的着重点不同。 在面向对象的分析和设计过程中，应用程序经常被建模成复杂层次结构的类，并且这些类被设计成尽可能贴近需要实现的业务逻辑。你通过从一个已有的基类继承并且专属化其行为来实现对已有代码的重用。问题在于继承实现重用是一个比较差的手段。当你从一个基类派生出一个子类时，必须完全了解基类的实现细节。例如，改变成员变量值会有什么边际影响，对基类中的代码会造成什么影响，重载一个基类方法并提供一个不同的行为是否会破坏那些预期基类行为的客户端代码？ 这种方式的重用通常被称着白盒重用，因为你要熟悉基类的实现细节。因此，白盒重用不能形成像在大企业的重用计划或者对第三方框架的方便采用时所需要的规模经济。 相反，面向组件编程强调黑盒重用，也就意味着允许你使用一个现存的组件，而不用关心内部实现，只要组件实现了一些预定义的操作或接口。作为组件和客户端之间使用的契约，面向组件的开发人员大部分时间花在分解接口上，而不是花力气设计复杂的类层次结构。 警告：.NET允许通过继承实现的方式使用组件，你的确可以使用这样的技术开发复杂的对象层次结构，然而，你应该尽可能保持你的类层次关系简单明了，而将精力集中在构建接口上。这样可以提升你的组件的黑盒