看透面向对象的复用技术【转】

想从面向对象复用技术中真正获益，你就必须理解不同种类的复用，并且自如地在不同场合下使用它们。

• 可复用资源
• 业务对象根源

复用性是面向对象技术带来的很棒的潜在好处之一。遗憾的是，很多情况下这个好处并不能真正兑现。原因在于复用并不是毫无代价的，它并不是你使用面向对象开发工具的时候就能轻而易举得到的。相反，它是你为了成功而努力工作得来的。首先要知道的是，这个世界上有比代码复用多得多的可复用的东西。代码复用只不过是最基本的一种形式而已。当然，你不要误解我的意思，代码复用当然是个好东西，只不过你可以靠其它种类的复用来取得更大的成就罢了。这里你会更关注整个应用，而不是源代码，那么你当然就可以复用其它的东西，而不只是代码。让我们来仔细看看各种复用的方式吧，怎么在你构建应用的时候恰当地应用它们。

代码复用

代码复用，是最常见的复用，指的是在同一个应用的多个模块中，或者是在多个应用下源代码的复用。理想状况下，代码复用可以共享通用类、函数集合或过程（在C++中是可以的，不过Smalltalk和Java不支持）来实现；即便是在最差的情况下，代码复用也可以通过拷贝和修改源代码来实现。现在，让我们回到糟糕的现实，工业生产对于代码复用还停留在仅仅是开发者拷贝粘贴代码的阶段。

代码复用的一个关键因素是你要能够获取到源代码。如果必要的话，你自己可以修改这段代码，当然也可以找别人帮你修改。这一点好坏并存，通过审读代码，你可以自己决定——哪怕这个决定很难做出——你是否要复用这段代码。同时，把代码开放给你，那么代码原作者也许会失去撰写说明文档的动力，这也就增加了你理解它所花费的时间，减小了你可能获得的收益。

代码复用的最大好处在于它可以减少你的代码量，也就潜在地减小了开放和维护成本。坏处则在于你自己应用的能力范围就被约束住了，而且也增加了应用和被复用代码之间的耦合。

继承复用

继承复用指的是在你的应用里面使用继承技术，以获取被继承类已经具备的行为，进而从对已有类的利用中获得优势。继承是面向对象核心基础的概念之一，适用于模型中“is a”、“is like”和“is kind of”这样的关系。举例来说，要开发一个CheckingAccount这样的类，你就得继承自SavingsAccount，直接复用它已有的行为来实现。

继承复用的好处在于你可以充分利用以前实现过的行为，减少开发时间，也就减少了你完成整个应用的开销。不幸的是，继承复用也有一些明显的坏处。首先，对继承的误用经常会让开发者失去组件复用这种更高层次复用的机会。其次，新人对于继承类的回归测试不够细致（父类和子类都要进行足够的测试），会导致产生一个不易维护和扩展增强的脆弱继承结构。总之，正如你所见，继承复用确有其物，但是代价太大。

模板复用

模板复用是文档复用的一种典型表现形式。它指的是对组织中关键开发文档、模型和源代码统一规划的实践。举例来说，组织中采用统一的文档模板来记载用例、状态报告、开发时间表、变更请求、用户需求、类文件和方法定义的文档头部。采用文档模板的最大缺点在于开发者会为了他们的使用方便而修改它们，却没能及时告知他的同事。

使用模板的理想结果，就是可以让开发者的工作变得简单。我见过开发人员共享像Microsoft Word一样简单的模板，也见过如Lotus Notes数据库一样复杂的模板。你的组织成员必须训练何时和怎样来使用模板，这样每一个人才会去使用并且正确地使用它们。

组件复用

组件复用指的是对预先构建和良好封装的组件进行复用的过程。组件往往是一个职责简单但五脏俱全的个体。组件复用和代码复用的区别在于，你是不可以访问到组件的源代码的。而它和继承复用的区别则在于，它不使用子类。组件复用的一个典型例子就是Java Beans和ActiveX。

组件复用的好处有很多。首先，它比代码复用或者是继承复用提供了更大的可复用性，因为组件是完整独立的个体，只需要把它引入就可以使用了。其次，由于通用平台的广泛使用，如Win32操作系统和Java虚拟机，为第三方厂商低成本创建和营销组件来获取利润提供了市场。组件复用最大的坏处在于组件很小，而且功能单一，你却可能需要为它们引入大量的库。

使用组件最简单的方式可以从使用用户界面widget的滑动条、图形组件和图像按钮开始（比如尝试去给它们取新的名字）。但是别忘了，一款应用可不仅仅只有用户界面。你可以获得像网络访问这样的操作系统功能特性，也可以获得像连接数据库来持久化数据的能力。如果你要构建自己的组件，请确保它功能单一，即只做一件事情。举例来说，一个编辑地址的用户界面组件可以具备很高的复用性，因为你可以在很多编辑界面上使用它。反之，一个同时具备编辑地址、e-mail和手机号码的用户界面组件复用性就比较差了，因为你通常不需要同时具备这三个功能。因此，最好的办法是拆分这三个功能，单独构建和在需要的地方重用每一个可复用组件。如果一个组件只做一件事情，那它就是一个高内聚的组件。

框架复用

框架复用指的是使用通用技术和业务对象，完成这样的一组类来实现基础的功能。开发者以框架作为应用构建的基础，也就是说，80%的活框架都替你做完了，你只需要完成剩下20%的工作。一种常见的形式是，让框架来完成GUI的基础组件。如今已有很多保险、人力资源、制造业、银行和电子商务方面的框架。框架复用体现了一种位于领域层面的高级复用。

框架总是为某一个问题域提供一个初始解决方案的，而且随着业务逻辑复杂化，需要耗费数年才能真正完善起来。框架的复杂性使得掌握它变得困难，需要开发者长期的学习过程。框架往往定位于特定平台上，把你视作它普通的用户，这也增加了你的应用的风险。虽然框架帮你完成了80%的工作，但是最困难的部分，业务逻辑和处理流程是你的组织所特有的，不得不由你完成。框架之间很难兼容，除非它们是一个人完成的，或者是同一个供应商提供的。这需要你不得不改变你的业务逻辑，以适应这个框架。

工件复用

工件复用指的是使用对以前创建的工件用例、标准文档、领域模型、过程指导和其它，来帮助你开始一个新工程。工件复用分为几个层次，从完整的拿来即用这种100%的完全复用，到仅以工件作模型之用，研究分析之以获取灵感。举例来说，编码和用户界面设计的标准文档对不同的项目来说，就是有价值的工件，像其中的建模符号定义和方法论总览这种文档，是可以直接复用的。我曾经为已有的通用数据接口以面向对象的方式做了包装，让这些类使用起来更直观。

工件复用提升了项目间的一致性，减少了各个项目的管理成本。另一个好处是你总是可以从网上发现和购买很多工件：用户界面标准对绝大多数平台来说都是很常用的；编码标准对主要语言来说都是不可或缺的；而标准面向对象方法论和模型记号这样的东西已经使用好多年了。主要的坏处在于很多核心程序员总觉得这种复用过了头，给彼此带来了强加的标准和过程约束。因此工件复用的底线就是当你觉得它是一种重要、可行和醒目的技术时，再去使用它。

模式复用

模式复用指的是使用公众总结认可的途径去解决常规问题。模式往往可以用1到5个类组成的简单类图来表达。模式复用，和代码复用显著不同的地方在于，你其实是在复用隐藏在代码后面的思想。模式复用是复用的高级形式，它被证明有很长的生命周期，至少超越了你正在使用的计算机语言，甚至超越面向对象范型本身。

“接触点（Contact Point）模式”，来自于我的一本叫做《Building Object Applications That Work》的书，它使用了UML1.1类图来建模，展示了一个寻找你的组织和其它业务实体之间接触点的通用模式。在这个模式下，你可以把邮件地址、实际地址和电话号码这些要素，都视作同一类供组织和其它业务实体（客户、雇员、供应商等等）交互的对象接触点。这个模式增加了应用的灵活性，你不但可以把发票以邮件形式发给你的客户，而且还可以决定是要以e-mail形式还是传真形式。你可以以电子产品的形式传输这个产品，而不是非得配送一张CD-ROM或者一盒视频磁带到某个地址去。接触点模式就是做这些事的关键先生。我已经成功分析了几类应用关于接触点模式的实现，复用了里面最困难的部分——为你思考背后的东西建模。模式复用是一种高级的复用，你完全可以用不同语言、不同平台去实现它。模式蕴含着最重要的开发价值——解决问题的思路。模式增加了使用常规途径维护和增强应用解决问题的能力，对于面向对象的开发者来说，价值是显而易见的。坏处在于模式复用并不能提供一种得之即用的解决方案，你不得不亲自实现模式的实际代码。

领域组件复用

领域组件复用指的是识别和开发大规模的可复用业务组件。领域组件是相关领域和业务类紧密结合的一组类。电信公司的组件图就包含若干领域组件，而每个组件都封装了一组类。服务提供组件封装了一百多个类，用以为远程呼叫、有线电视和互联网服务。在新应用的开发阶段，领域组件通过架构驱动的模型访问，修改和增强。

领域组件已经显出巨大的可复用潜能，因为它们反映出大规模的业务行为内聚的特征，在许多应用中都是一致的。你在领域开发中创造的每样东西都是可以复用的。与后期的复用相比，领域组件在前期业务行为和组织的架构设计中显出更大的作用。

对以上的复用方法，好消息是，它们是可以同时被采用的。框架复用经常会将你的设计限制在框架的架构和使用规则的局限上，但是你仍然可以在框架上面好好利用其它的复用方式。工件和组件复用是最容易上手的形式，只需要一点点的调查，很容易就找到可复用的工件或组件。

你可以在线订购文档模板，但是如果你的组织没有制定完好的开发流程，你也许从这些模板中获得不了太多东西。继承和模板复用是建模工程师熟悉的领域，其实从一开始他们就在采用这些复用形式了。

现实地说，我会以工件和模板复用开始，来训练我的建模工程师，正确使用继承和模式复用，来以架构驱动方式识别开发领域模型的组件，我相信程序员会尽可能地复用它们。

分类视角

既然我们已经掌握一些可复用工具了，那就让我们来看看该怎么用吧。总共有4层架构分类，标识着我们对相应每一层的复用能力。因为每一层都有它自己特有的属性和开发方法，因此试着在每一层培养复用技巧是相当有意义的。现在让我们具体来看。

用户界面层封装了屏幕显示和报告信息，能够体现出用户和应用交互的情况。界面层最常见的复用类型，显然是接口widget的组件复用，因此开发者很可能会购买滚动条、图像、链表和其它widget的组件库。最重要的层次是工件复用，特别是用户界面和报告信息布局标准的复用。在界面设计中最重要的一件事是一致性，最简单的办法是采用标准和原则来构建你的应用。

业务层封装了应用的问题域逻辑。模式复用，尤其是分析模式复用，和框架复用的业务模型与通用业务类库的复用一样，是业务层十分重要的事。虽然这三种复用方法的应用还远没成熟，但它们在业务领域中的发展却是非常迅猛的。大型模式集合在学术和商业界争先发展，通用框架在具备垂直市场的大型咨询和技术公司不断被重构优化。

业务层更重要的复用，还是在你的组织中真正引入领域组件。架构驱动的开发是基于复用的，领域组件和产品一样重要。

持久层的封装和一般化，采用多种持久化机制，永久地存放对象到关系数据库、对象数据库或者文本文件中去。这一层复用最重要的形式是框架复用和组件复用。这是因为你可以购买完整或者部分实现持久层的包。模式复用也可能很重要，持久层的设计会以多种形式展现出来。此外，组织中数据字典的工件复用也可能会成为重要的一份子。

系统层封装和一般化了操作系统、网络、硬件和其它应用。设计模式复用，尤其是硬件和应用的包装，在系统层中是非常普遍的，以组件和工件复用的形式表现出来。

在这4层内部，代码和继承复用显然是最有价值的。当然，你也可以争辩说模式复用可以在用户界面层中实现。对一个完整的项目来说，标准文档布局和开发标准、过程下的模板复用也是不容忽视的。

复用的成功之匙

那么，怎样才能真正做到面向对象复用呢？我想说，你应该这样开始：去买一堆工具，还有一个仓库来存放你可复用的的工作成果。可惜的是，复用可不仅仅是工具而已。事实上，很多组织都因为过于专注于工具而不是过程可悲地失败了。这里有一些复用的小诀窍：

• 你只能在某样东西至少在不同项目里被复用三次以上以后，才能称呼它为可复用的。 你可以尝试可复用的设计，但是直到你的设计被复用三次，你才可以谈成功的设计。可复用性是旁观者来下结论的，而不是设计者自己。
• 可复用性必须保证文档完备，至少具备一个怎样使用的实际例子。 此外，文档必须标识出，什么时候不要复用它，这样开发者才能理解合适场景的上下文。
• 真正实现复用的唯一途径是好好准备它。 你必须分配必要的时间和资源来确保你的工作可复用。如果你不回首花时间来一般化你的工作，复用就不可能发生。项目压力会迫使你把可复用化的工作搁置，直到你真的有时间去完成它。在这里，底线就是对复用的管理，特别是对已有资源的复用，把它们持续加到可复用仓库中，这可能并不是你当前工作的一部分，但是你不做，复用就无从谈起。
• 复用是一种态度。 当你新建一个工程的时候，第一件事应该是决定你的应用还会以怎样的方式在别的场合被复用。也许有些人已经构建了你需要的东西，或者你可以购买一些其它可复用组件。另一方面，你得主动分享你的工作成果，这样大家才可以复用它。一个好领队会在团队中持续地寻找复用点和提升、奖励复用的机会。一个不错的方式就是在从这样两个方面去寻找可复用的机会：模型评审过程中，寻找继承和模式复用的机会；代码走读过程中，寻找组件和代码复用的机会。

有时你会患上“非我发明”（NIH）综合症，这是一个阻止你在不同团队中传播复用精神的壁垒。由于NIH综合症，开发者没法复用其他团队的工作成果，仅仅是因为这些东西不是自己创造的。这种逻辑真是狗屎啊，职业的开发者会在工作中持续地寻找可复用的机会，因为那会将他们从繁重工作中解放出来，有更大的精力去关注那些他们自己应用中特有的问题。我的经验是，只要职业开发者遇到了满足当前需求的，高质量、文档完备和易于理解的组件，他们会很快地复用它们。NIH综合症就是一个笑谈，如果那样的话，面向对象开发环境不应该关联那么多类库，成百上千的靠卖可复用组件和框架的公司就倒闭了。

我们总是在说人们怎么去发现那些可复用的东西，没错，这里我还要说，复用仓库真是一个好东西，它和组织命令中的官方链的概念差不多。就像通过官方渠道和通过私交网络的比较一样，你可以同时在仓库和你朋友那里发现可复用的组件。

可复用是一个组织级别的事情，而不是一个项目级别的事情。很多组织在尝试复用的过程中失败了，因为他们根本不理解这一区别。项目之间的复用，是指你因复用的获益并不是在当前项目。很多组织在他们没有完成第一个项目的时候就过早地放弃复用了，如果这样你就觉得没啥可复用的，那这想法就太愚蠢了。这就是为什么架构驱动开发如此重要，因为它超越了单个项目的需求，是为了满足整个组织的需求的事，一个重要的组织层面的需求，就是要尽可能复用已有的工作成果。

一个万能的可复用解决方案是不可能实现的。有很多不同的可复用组件，都是为了满足特异的不同层面的需求，需要不同的处理方式。因此你需要准确地识别和适宜地计划。

理解不“重复发明轮子”的含义，首先你至少具备不止一个轮子。你可以复用源代码、组件、开发工件、模式和模板。最重要的是，你的工作不是可复用的，而且它是面向对象的。那么，你就该花时间把它变成可复用的。