复用性是面向对象编程模型的最主要的特点之一，而在现实中的使用情况却不尽然。面向对象可复用性并非免费的午餐，只是依靠开发工具带来的帮助是远远不够的，必须付出更多的努力你才能更好的享用它。下面我们要讲述的不仅仅是代码复用还有比代码更多的东西需要我们用复用的视角去关注它。在这些可复用的资源中，代码复用无疑是最不具实力的一种复用形式。
请不要认为这是笔误，以我的观点代码级的软件复用仅仅能够使我们的程序不会变得更坏，除此之外大堆大堆的代码库没有更多的价值。要使我们的软件朝着更好的方向发展，重视其它形式的面向对象可复用性将会起到显著的作用。让我们一起来学习各种形式的可复用模型以及如何将这些优势运用到我们的应用程序中去。
代码复用
代码复用，可复用性的一种最常见的形式。可能会有一个或多个程序使用到这段复用代码，也就是最常见的情况复用代码被共享为公共类或是函数库或是过程（过程方法经常在C++中使用而在一切以面向对象为基础的Java和SmallTalk中是没有过程方法的）。然而糟糕的是代码级的复用通常被实现为对现有代码的复制和修改，以至于程序员在日常的开发中对此形式欣然接受而并未感觉到问题严重性。
原因在于代码级的软件复用其源代码对于任何人都是公开的，如果有需要任何人包括你我都可以按照自身的要求修改代码。那么这样以来使用代码级的软件复用将是一把双刃剑，一方面你可以自己决定是否使用或者何时使用它；另一方面作者如果以源代码的形式推出使用版本，这将使作者没有更多的动力去维护相关的文档，而这样做的结果是增加了学习的难度和门槛。
代码级软件复用最大的好处在于可以大量减少重复代码的出现，降低了开发和维护成本。不利之处在于，它的作用范围仅限于程序的编写而且会造成程序结构过分耦合。
模版复用
模版复用是一种典型文档说明性复用。它通常被实践于运用一系列规定格式管理手工书写的文档，建模模型以及程序代码。例如，模版复用形式经常被组织机构采用并用来规范用例说明，状态报告，开发进度，需求变更，用户需求，对象结构以及方法说明等文档。文档模版形式的最大的好处在于对于手工书写文档的统一性和质量有了较好的保证。而最大的缺点在于使用者常常会因为个人的需要而修改文档规格造成混乱。
文档模版的最佳使用原则既是使其使用者能够非常容易的接受。我所见过的比较简洁文档模版即微软的文档模版而比较复杂且需要多人共享的模版非（Lotus Notes）莫属。因为你的组织需要围绕文档模版的使用进行培训，以便大家都可以一致，正确的使用文档模版。
组件复用
组件级的复用性体现在利用一些预生成好的，模块化程度高组件进行程序开发。组件通常是在某一个方面的能够高效解决问题的对象集合。组件级别的复用性不同于代码共享，因此不需要开发者直接访问原始代码。同继承级别的复用性也有着本质的区别因为不需要引入子类的概念。组件复用最常见的例子就是JavaBean和 ActiveX控件。
使用组件级的软件复用有着很多的优点。首先，组件具有的模块独立性使得它能够方便的插入你的应用程序中，而此特性使得组件级复用的适用范围大大超过代码级复用和继承级复用。其次，广泛存在的基础平台例如Win32和Java平台都为第三方厂方开发和销售他们的组件提供了便利。对于组件级复用最大的不足之处在于组件独立性要求其粒度要足够的小，因此我们将需要管理大量的组件对象。
使用组件进行开发最常碰到的方面就是用户界面组件了，例如滑动条，图像组件和按钮组件，然而应用程序中使用组件的机会要远远大于用户界面。你可以把进行网络访问和链接数据库的功能模块封装成可用性更高的组件。如果你自己要实现一个组件，那么尽量保持这个组件功能的单一性吧。比如说一个供输入普通地址的组件将会在很多界面中被用到。而一个同时供输入普通地址，e-mail地址和电话号码的组件，当其集以上三个功能于一身时可重用性将会大打折扣。明智的方案是分别创建三个可重用的组件。因此一个组件对某方面的功能的封装性越高其可复用性也就越高。
框架复用
在实现了基本功能和业务对象的基础上进行的开发通常称之为框架复用。开发人员在框架的基础上进行开发，只需要完成应用程序最终20%的部分而例外80%的部分已经由框架完成了。框架的应用在用户界面编程中经常出现，还有一些成熟的框架模型被应用在保险，人类资源，制造业，银行和电子商务软件开发中。框架级别的复用性体现了从较高的领域对象复用的特点。
框架对业务领域重点提出了相应的解决办法并将那些复杂的需要花费时间进行开发验证的复杂逻辑进行了良好的封装。同时框架复用也有自身的缺点，框架的复杂程度给使用者的学习和使用带来了一定的难度。通常情况下框架的使用者会被绑定在一个厂商，这会增加应用程序的开发风险。其次尽管框架已完成了尽80%的基础功能，但剩余的20%和具体业务，流程相关的需求还需要我们来实现。我们还常常因为要使用框架不得不修改已有的业务逻辑以适应框架的特点，只有使用通用的厂商和组织下的框架我们才可能避免刚才的麻烦。
工程产出物复用
工程产出物复用包括使用以前创建的用例，标准文档，模型，过程方法和计划以及应用程序等。工程产出物的复用给新的工程的展开提供了坚实的基础。工程产出物的复用可以区分为几种程度，例如照搬旧工程的应用到新的工程中并在此基础上进行实践。编码格式和应用程序规格在项目之间都可以通过形成建模辅助说明和经验总结文档进行沟通。通过对已有应用程序的修改和包装，同样可以完成对已有工程产出物的复用。
项目产出物的复用保证了项目之间的一致性并减少了组织新项目的负担。此外，你还可以方便的在线购买或是查找一些产出物：例如多个平台下的用户交互控件，主流语言的编码规范，面向对象的方法学以及建模说明等。.而规范标准和时间流程可以很容易的进行变更，这使得基于产出物的复用性概念往往被架空而得不到实践，我们要在应用程序开发中仍不要忽略了对已有产出物的复用。
模式复用
模式复用指的是利用已被反复实践的规则解决通用性问题。它常常被描述为一个单独的类对象当通常的情况下一种模式包含一到五个类。模式的复用的思想是将复用代码背后的思想进行了抽象从而形成一种应用规则。它是一种高层次的复用机制，其生存期远远超过了描述它的语言甚至是规范它的面向对象思想。
联络点模式是我在Building Object Application 一书中所描述一类问题的解决规则。利用通用建模语言建立的联络点模型展示了对机构之间的联络方式进行分组的通用解决规则。
模式使用的场景描述了你的组织在与客户，雇员以及供应商进行交互时所使用的联系方式例如e-mail,普通邮件地址，电话等，都可以被看作一种联系方式，因此联络点模式增加了应用程序的灵活性。利用联络点模式你不仅可以使用邮递将发票送给客户，还有电邮和传真的方式可以使用。同样你可以利用英特网代替普通邮件为你的客户送上需要的视频信息。联络点模式很好的满足了上述的情况，我也在很多的项目中实际运用了该模式。模式复用提供了更高层次的复用和跨平台，跨语言的特性。模式将众多复杂问题的解决思想进行了抽象，使得模式的使用增强了应用程序的可维护性。但模式复用并不是一劳永逸的工具，我们仍需要自己在项目中去实现它。
领域组件复用
领域组件复用主要涉及到确立和开发大范围的可复用性商业组件。某个领域方面的组件常常是一系列关系紧密，完成具体功能的商业对象组合。通过对电信企业某个商业组件的描述图可以看出，每个组件都是包含了多个类对象的功能聚合体。例如，服务提供组件包含了100多个类对象，其功能涉及长途电话业务，有线电视业务和互联网服务业务等。领域模型的初始化确立是指以架构驱动为基础来管理应用程序的建模，修改和补充。
领域组件的复用性具有很大的潜力，主要表现在大量已有的，关系紧密的商业功能在许多的应用程序中都会用到。任何领域对象都应该被设计为可重用的，因为领域对象可以高效的融入商业功能中并为今后的管理和重用提供了基础。
令人高兴的是我们可以将上述几种复用方式结合在一起使用。可以肯定是，框架级别的复用性要求将关注点放在框架结构，规定以及针对性的培训上，但是我们同样可以享受其它重用方式带来的好处。项目产出物和组件级别的重用是非常容易实践的，只要花费少许时间我们就能发现许多可重用的东西。
模版复用同样可以从网上获取相应的资源，但这里有所不同的是如果我们的机构没有形成一个很好的处理流程的话，那么模版复用的所带来的好处将会大打折扣。继承和模式复用都是需要建模时期考虑的，如果要在实际项目中使用它们是需要花费时间学习的。
回到现实中来，我会用项目产出物复用和组件复用的思想来培训相关的架构师，并在适当的时候引入继承复用和模式复用或是实现基于架构驱动的领域组件复用。还有一点就是要相信我们的开发人员，他们可以处理好代码级的复用。
京公网安备 11010802021500号