[翻译]面向对象重用详解

原文在这：http://www.ddj.com/architect/184415594?cid=Ambysoft

 

为了获得面向对象重用的好处，你必须懂得各类的面向对象重用手法，并且要知道在哪里以及如何运用它们。

可重用性是面向对象技术的一大特点。然而遗憾的是，这个特性往往不容易应用于实践中。原因是，重用也并不是免费的，并不是说你使用一些面向对象开发工具就可以简单达到的。相反，你必须付出很大的努力才能达到较好的重用。第一个要面对的问题是，应该是重用而不是仅仅是代码重用。代码重用是重用技术中效率最低的一种方式。这里不要误解我的意思，代码重用还是一种好的方法，但是有可能对你的其他地方的重用造成一些隐患。我们是在开发应用程序，而不仅仅是写代码，所以你应该更多的考虑重用而不是代码重用。下面，让我们详细地看看各类的重用技术，看看当你在开发应用程序的时候，什么地方你可以使用它们。

代码重用

代码重用为最常见的一种重用方式，可能是同一个应用程序中一些部分源代码的重用，也可能不同应用程序中重用。在最好的情况下，可以通过共享一些类或者一些功能块或程序段（C++中可行，Smarttalk和Java不不行）来达到代码重用。在最坏的情况下，可以通过复制，然后修改代码来达到代码重用。在业界，一种可悲的现状是，代码复制为开发者使用的唯一的一种代码重用方式。

代码重用的一个关键点是，你已经弄清楚了源代码。需要的话，你可以自己修改来重用，或者让别人帮你修改。这样有好有坏。通过阅读代码，虽然这样做常常比较慢，但是你可以决定是否使用它。但是，另一方面，由于整个代码都给你了，而代码的最初编写者可能没有很好地编写一些文档，这样则可能增加你理解代码的时间，结果减少代码重用带来的好处。

代码重用最主要的好处是可以减少你实际需要编写的代码量，从而间接减少了开发和维护的成本。缺点是代码重用的效果仅仅局限于开发，而且它常常会增加应用程序的耦合性。

继承重用

继承重用意味着在你的应用程序中使用继承，从而可以直接使用一些已经存在的类实现好的行为。继承是面向对象的基本概念，它可以让你对“is a”，"is like"，"is kind of"等概念进行建模。例如，为了开发一个“ CheckingAccount”的类，你可以让它继承自" SavingsAccount"，然后直接重用后者实现的所有行为。

继承重用的好处是你可以直接使用先前开发好的行为，这样能同时减少开发和维护的成本。但是，很遗憾，继承重用存在一些缺点。第一，继承的错误使用常常会导致开发者无法进行模块重用，而模块重用可以提供更高层面的重用。第二，初级开发者往往会忽视对继承的回归测试（在一个子类中运行父类的测试用例），从而导致脆弱的类继承体系，最终难以维护以及增强。如你所见，这也是重用，但是应该避免。

模板重用

模板重用为文档重用的一种形式。它一般指组织内部一些重要的文档、模型、源代码的共同格式或风格。例如，组织内部很常见的一些共用的模板，如用例、状态报告、开发进度安排、变更报告、需求、类文件以及方法注释等。文档模板的主要优点是可以增加文档的一致性和质量，而缺点是开发可能根据自己的想法修改模板，但是修改后没有与项目成员说明。

使用模板的最好效果是，你可以让开发者非常简单的使用他们。我见过一些模板的实现， 简单的如Mirosoft的Word文档的模板，复杂的如Lotus Notes，带有一个可以被所有开发者共享的数据库。你的组织也必须提供一些培训，以便组织内的每个人都能正确地知道在何时如何使用何种模板。

组件重用

组件重用指在你的应用程序开发过程中使用先前已经构建、而且完全封装好的组件。组件一般是自成体系的，并且仅封装了一个完整概念。与代码重用不用，组件重用无需你去看源代码；而与继承重用不同，组件重用无需你使用子类。Java Bean和ActiveX为比较常见的组件。

组件重用有几个优点。第一，组件重用比代码重用或继承重用提供更广泛的可重用性。因为组件是自成体系的，所以使用时你仅需插入他们，然后他们即可工作。第二，一些通用平台（如Win32操作系统，Java虚拟机）的广泛使用开辟了一个巨大的组件市场，第三方的计算机厂家可以自己开发并且以一个比较低的价格销售这些组件。组件重用的缺点是，组件一般比较小而同时封装了一个完整的概念，所以往往需要大量的与他相关的开发包。

用户接口是使用组件的最简单的方式，如状态栏、图形化组件、图形化按钮等。但是别忘了，除了用户接口外对一个应用程序来说还有很多其他方式。你可以获取一个封装了操作系统网络能力的组件，或者一个封装了持久层能力的组件（如与关系数据库交换的组件）。如果你想构建自己的组件，那么确保他们仅仅只做一件事情。例如，一个用于编辑信件地址的组件就具有很好的重用性，因为你可以很多需要编辑邮件地址的场合。而一个可以用于编辑信件地址、E-Mail地址和电话号码的组件则不是很好重用，因为没有多少场合同时需要这三个特性。相反，最好是构建三个这样可重用的组件，在需要的地方挨个使用即可。当一个组件只封装了一个概念的时候，它是一个内聚的组件。

框架重用

框架重用是指使用一系列已经实现好的、与某项技术或商业领域相关的、提供基础功能的类。开发者以框架为基础开始构建他们自己的应用程序。在此过程中，80%的通用基础框架已经构建好了，你只需增加与你应用相关的20%即可。实现了GUI基础组件的框架是一个很常见的例子。有各式各样的框架应用不用的领域，如保险业、人力资源、制造业、银行业、电子商务。框架重用是一种领域层面的高级重用技术。

框架提供了对问题域的一个基本解决方式，并且封装了一些比较复杂的逻辑，而这些逻辑的开发可能需要花费数年的时间。然而很不幸，框架重用需面对一些不足。复杂的框架难于掌控，对部分开发者来说，需要一个较长的学习时间。框架往往是与平台相关的，这样会使得你的应用与某个计算机厂商绑定，从而增加应用的风险。虽然框架实现了你需要的80%的逻辑，但是它们往往是最简单的那80%；而比较困难的那部分，比如商业逻辑或者对你组织而已需要特殊处理的逻辑，则还需要你自己来实现。框架之间通常不能同时工作，除非他们是来自同一个计算机厂商或者是协会的。他们往往需要你改变自己的应用来适应框架的变化，而不说使用其他方式。

现有重用

现有重用是指使用先前已经开发好的一些东西，如用例、标准文档、领域模型、流程、纲要和一些可以让你的新项目尽快开始的参考项目。现有重用有几种不同的级别，有完全的重用，如：你可以完全把现有的项目作为你的新项目或者把它使用到新项目中，也有很少重用，如，你可以看看以前的项目，获得一些想法标准文档，如编码标准和用户接口标准是一些很好的现有的东西，可以作为一些模型文档和方法指导文档在项目之间重用。我们也能够通过一般数据接口或者通过使用面向对象的方式进行包装来重用现有项目。

现有重用强调项目之间的一致性以及减少对每个新项目管理上负担。另一个好处是，你可以买到一些现有的东西或者在网上找到这类东西，如：用户接口标准（大部分平台都有），主流语言的编码标准，面向对象方法来的标准，建模符号的标准（早就出现很多年了）。现有重用的最大缺点是，它常常被一些顽固不化的程序员认为过度使用了，因为你仅仅是把一些标准和流程从一张桌子搬到另一个。总之，现有重用非常重要而它是一种需要长时间积累的技术，不应该忽略它。

模式重用

模式重用是指重用一些公开的、文档化的的方法来解决一些常见问题。模式一般由单个类图来描述，通常有一到五个类。使用模式重用，你不是重用代码，而是重用这些代码背后的思想。模式是一种很高层面的重用，而且有很长的生存期——至少超过你正在使用的计算机语言，而且有可能超过面向对象语义本身。

接触点模式（ The Contact Point ），从我的书（Building Object Applications That Work）修改而来，使用了UML（统一建模语言）类图进行建模，展示了一种能够跟踪你的组织与其他商业组织之间的接触点的通用模式。这个模式说明你可以把E-Mail地址、通信地址、电话号码等看做同一类东西，可以称之为对象接触点，通过这些接触点，你的组织可以与其他商业组织（如：客户、员工、供应商等）进行交互。这个模式增加了你应用程序的可扩展性。举例说，你不仅可以邮寄一份发票给客户，同样也可以使用E-Mail或者传真给客户；无需邮寄一个光盘或录像带到某个通信地址，你可以以电子的方式传送这类产品。接触点模式是以上这类事情成为可能的关键一环。我已经在机构应用中成功的使用了此分析模式，并且重用了这个模型最困难的部分——模式背后的思想。模式重用是一种高层面的重用，你可以跨越多种语言和平台来实现这种重用。模式封装了开发中最重要的一个方面——解决问题的方法。模式增加了系统的可维护性，并且通过使用被广大经验丰富的面向对象开发者所认可的解决问题的通用方式，来增强你的应用程序。模式重用的缺点是，模式无法提供即时的解决——你必须编写代码来实现模式。

领域组件重用

领域组件重用是指对大型的、可重用的商业组件的识别以及开发。一个领域组件是能提供一组内聚的功能的相关领域和商业类的集合。例如，一个电信公司的组件图上有几个领域组件，每个封装了很多类。服务提供组件封装了100多个类，从处理长途电话的类，到有线电视的，到互联网服务的都有。在你的组织中，一个新项目一般通过架构驱动的建模过程来识别出各个领域组件，然后在开发过程中进行修改和增强。

领域组件能够提供最强的可重用性，因为领域组件封装了大规模的、内聚的商业行为，而这些商业行为可以应用到很多应用程序中。你在针对某一领域进行开发的所以东西，都应该考虑重用。领域组件是高效的架构级工具，他对商业行为进行了很好的封装以便日后重用。

对于以上这些重用方法，一个好消息是你能同时使用他们。没错，框架重用往往把你限定在某些框架或者一些标准或者一些指导方针中。但是，你同样可以和框架重用一起使用其他重用。现有重用和组件重用是两种开发新项目最简单的方式；通过一点研究，你很快就会发现可以重用的东西。

你可以在网上买一个文档模板，但是如果你的组织内部没有很好订阅开发过程的话，你可能无法享受模板带来的好处。继承重用和模式重用是建模者需要掌握的，他们会发现，应用这类重用是必修的一课。

从实践角度说，我一般会使用现有重用和组件重用来训练我的建模人员，然后让他们适当的使用继承重用和模式重用；使用架构驱动的开发方式来识别和开发领域组件；至于开发人员，我很信任他们，他们可以使用任何他们能用的重用方式。

从类的角度看待重用

现在，我们已经有了一些重用的工具，下面让我们看看如何应用他们。四层的类架构说明了在每一层如何使用重用。因为每一层有它自己独特的属性和开发要求，所以在每一层也应该使用适当的重用方法。让我们来看看每层的具体情况。

用户接口层封装了屏幕和报表等，一些用户用于与你的应用程序交互的东西。对于用户接口层，最常见的重用方式显然为界面的组件重用。开发者常常会购买一些开发包，如：滚动条、图表、列表和其他一些界面组件。现有重用对这层也很重要，例如，一些特有的用户接口或者报表格式标准的重用。在设计用户界面时，最重要的事情是一致性，而在你的应用程序中遵循一定的标准和指导原则是实现一致性的最简单的方式。

业务层封装了你的应用程序需要解决的问题的处理逻辑。模式重用，特别是分析模式重用，对业务层而言很重要。同样，对业务层而言，框架重用以及一类基本业务类包的使用，也很重要。虽然这三种重用方式还相当地不成熟，但是他们正在很多商业领域中快速地发展。大量的模式正在从学校和企业中诞生，而一些基础框架正在被大型的咨询和技术公司创造，这些公司往往在一个或多垂直领域拥有领先水平。

然而，对于你的组织而言，更重要的是引入领域组件的重用。领域组件是以架构驱动、以重用为目的开发的一个重要副产品。

持久层封装并且抽象了你用于长期存储对象的不同持久化机制，例如：关系数据库、对象数据库或一般的文件方式。对这一层而言，最重要的重用方式为框架重用和组件重用。这是因为你能够购买完整实现的或者部分实现的持久层的包。使用设计模式重用的可能性也很大，因为对持久层的设计方式已经有一些公开的出版物了。同时，组织内部的数据字典的现有重用也是有可能的。

系统层封装和抽象了对操作系统的操作，如网络、硬件和其他一些应用。设计模式的重用，尤其对硬件和应用的封装，对系统层而且很常见，对一些包装类的组件重用和现有重用也很常见。

在这所有四层中，代码重用和继承重用显然都是适合的。当然，你也可以说在用户接口层也可以使用模式重用。在整个项目中，对标准文档、开发文档的格式和流程的模板重用，具有重要意义。

成功使用重用的秘诀

你如何才能真正地达到面向对象的重用呢？我想你所需要做的，就是走出去，买一些工具或者存储库来存储的你的可重用的东西作为一个开始。当然了，重用不仅仅只是工具。事实上，很多组织的重用失败就是因为太注意了工具，而不是流程。这里是一些重用的建议：

    当一个东西被不同的组、使用在不同的项目至少三次以上后，你才能称它为可重用的。你可以在设计的适合就考虑重用，但是只有当此应用的某些部分被使用了三次以上时，你才能说这个重用是成功的。

    可重用的东西必须有很好文档，同时还要有一个或几个展示如何使用它们的实际例子。同时，文档还应该说明什么时候适合用它，什么时候不应该用，以便开发者能知道它使用的场合。

   把重用应用于实际的唯一方法是你时刻在为重用做准备。你必须划出一些必要的时间和资源，来确保你的工作可以重用。如果你不回顾并且花一些时间来总结一下你的工作的话，你是不可能做到重用的。因为项目的压力总在促使你把这些事情放到一边。底线是，重用的管理（明确地重用一些东西、持续地增加一些可能重用的东西到重用库中）是否是你工作的一部分，如果不是，则无需考虑。

   重用是一种态度。当你开始一个项目时，你需要考虑的第一件事情就是你是否可以在应用中的某些部分重用其他项目的一些东西。可能其他人已经把你需要的东西做好了，可能你可以购买到一些组件或者可重用的东西。另一方面，你必须乐意与其他人分享你的工作成果，这样他们就能重用你的东西了。一个优秀的项目领导者，必须时常地去发现一些可以重用的机会，去促进重用，并且最终使得他的队伍从中受益。在开发的各个阶段寻找重用，是实现重用的一个很好的方式：在建模阶段，寻找继承重用和模式重用；在编码阶段，寻找组件重用和代码重用。

经常地，你可能不得不与“非创造者”（NIH）症状做斗争。这个问题会阻止你在你的团队中传播重用的思想。对于NIH症状，开发者会拒绝重用其他开发者的东西，因为这个东西不是由他们自己开发的。 Pure hogwash，一名专业开发者，时常在其他项目中寻找一些他可以重用的东西，因为这样可以让他们在开发自己的应用某些部分时，免去一些领域相关的工作。我的经验是，比较专业的开发着往往乐意使用其他开发者的工作成果，当然，这些工作必须是高质量的、有很好文档的、并且简单易懂的。NIH症状是虚构的，如果是真的，那么面向对象开发环境就不会有这么多类包了，当然，也用不着数百家公司出卖可重用的组件和框架了。

语言上的沟通往往是人们发现重用的一个方式。不错，重用库中放了很多好东西，但是，它跟你组织内部其他一些官方的束缚差不多。你可以通过官方渠道或者通过非正式的网络渠道获取重用库中的东西，当然，你也可以从朋友那里获取。

重用是一个组织的事情，而不是一个项目的事情。很多组织因为不知道重用的范围而导致重用失败。项目之间的重用能使你从重用中受益，不要仅在单个项目中重用。很多组织因为在第一个项目中无法达到重用而过早地放弃了重用，其实这是很愚蠢的，因为刚开始的时候，你确实没有什么可重用的东西。这也是使用架构驱动开发的一个重要原因，因为它往往能看到比一个单独项目更长远的东西，这些东西能满足整个组织的需要，并且对于那些重要的需求，在任何地方都应该考虑重用的规划。

那种在任何地方都适用的重用是不实际的。有很多种方式可以实现重用，不同的层次上有不同需求需要不同的重用方式的组合。你必须知道并且根据情况做合理的计划。

至于“不用重新发明轮子”这个说法，首先你需要知道的是，你手上有不止一个轮子供你使用。你可以重用源代码、组件、现有的开发需要的东西、模式和模板。但是更重要的是，你需要知道，你的工作是不可重用的，因为它是面向对象的。相反，你需要花时间在上面，让他们可以重用。