高质量代码三要素

高质量代码的三要素

我们评价高质量代码有三要素：可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。

1.可读性强

一提到可读性似乎有一些老生常谈的味道，但令人沮丧的是，虽然大家一而再，再而三地强调可读性，但我们的代码在可读性方面依然做得比较糟糕。每当我看到大段大段、密密麻麻的代码，而且还没有任何的注释时常常感慨不已，深深体会到了这项工作的重要。由于分工的需要，我们写的代码难免需要别人去阅读和维护的。而对于许多程序员来说，他们很少去阅读和维护别人的代码。正因为如此，他们很少关注代码的可读性，也对如何提高代码的可读性缺乏切身体会。有时即使为代码编写了注释，也常常是注释语言晦涩难懂形同天书，令阅读者反复斟酌依然不明其意。针对以上问题，我给大家以下建议：

1）不要编写大段的代码

如果你有阅读他人代码的经验，当你看到别人写的大段大段的代码，而且还不怎么带注释，你是怎样的感觉，是不是“嗡”地一声头大。各种各样的功能纠缠在一个方法中，各种变量来回调用，相信任何人都不会认为它是高质量的代码，但却频繁地出现在我们编写的程序了。如果现在你再回顾自己写过的代码，你会发现，稍微编写一个复杂的功能，几百行的代码就出去了。一些比较好的办法就是分段。将大段的代码经过整理，分为功能相对独立的一段又一段，并且在每段的前端编写一段注释。这样的编写，比前面那些杂乱无章的大段代码确实进步了不少，但它们在功能独立性、可复用性、可维护性方面依然不尽人意。从另一个比较专业的评价标准来说，它没有实现低耦合、高内聚。我给大家的建议是，将这些相对独立的段落另外封装成一个又一个的函数。

许多大师在自己的经典书籍中，都鼓励我们在编写代码的过程中应当养成不断重构的习惯。我们在编写代码的过程中常常要编写一些复杂的功能，起初是写在一个类的一个函数中。随着功能的逐渐展开，我们开始对复杂功能进行归纳整理，整理出了一个又一个的独立功能。这些独立功能有它与其它功能相互交流的输入输出数据。当我们分析到此处时，我们会非常自然地要将这些功能从原函数中分离出来，形成一个又一个独立的函数，供原函数调用。在编写这些函数时，我们应当仔细思考一下，为它们取一个释义名称，并为它们编写注释（后面还将详细讨论这个问题）。另一个需要思考的问题是，这些函数应当放到什么地方。这些函数可能放在原类中，也可能放到其它相应职责的类中，其遵循的原则应当是“职责驱动设计”（后面也将详细描述）。

在编写代码的过程中，通常有两种不同的方式。一种是从下往上编写，也就是按照顺序，每分出去一个函数，都要将这个函数编写完，才回到主程序，继

续往下编写。而一些更有经验的程序员会采用另外一种从上往下的编写方式。当他们在编写程序的时候，每个被分出去的程序，可以暂时只写一个空程序而不去具体实现功能。当主程序完成以后，再一个个实现它的所有子程序。采用这样的编写方式，可以使复杂程序有更好的规划，避免只见树木不见森林的弊病。

有多少代码就算大段代码，每个人有自己的理解。我编写代码，每当达到15~20行的时候，我就开始考虑是否需要重构代码。同理，一个类也不应当有太多的函数，当函数达到一定程度的时候就应该考虑分为多个类了；一个包也不应当有太多的类

在aside的源码中，对包的组织是比较规范的，但很多action中存在大量大段代码的函数并且缺少注释，比较典型的有ModuleInfoAction、FileInfoUploadAction，QueryModelAction。里面都有好几百行的函数，甚至一个700行的类一个函数就占了一大半。

2）释义名称与注释

我们在命名变量、函数、属性、类以及包的时候，应当仔细想想，使名称更加符合相应的功能。我们常常在说，设计一个系统时应当有一个或多个系统分析师对整个系统的包、类以及相关的函数和属性进行规划，但在通常的项目中这都非常难于做到。对它们的命名更多的还是程序员来完成。但是，在一个项目开始的时候，应当对项目的命名出台一个规范。譬如，新增记录用new或add 开头，更新记录用edit或mod开头，删除用del开头，查询用find或query开头。使用最乱的就是get，get开头的函数应该仅仅用于获取类属性。

在aside中，ModuleInfoAction这个类的命名就非常奇怪，这是一个用来做走查的类，却起了这样一个名字，看的我非常迷惑。MissionAction，MissionManager中的命名也非常古怪，getMissionTargets02，getMissionTargets这样的函数命名很难理解

注释是每个项目组都在不断强调的，可是依然有许多的代码没有任何的注释。为什么呢？因为每个项目在开发过程中往往时间都是非常紧的。在紧张的代码开发过程中，注释往往就渐渐地被忽略了。利用开发工具的代码编写模板也许可以解决这个问题。

用我们常用的Eclipse为例，在菜单“window>>Preferences>>Java>>Code Style>>Code Templates>>Comments”中，可以简单的修改一下。

“Files”代表的是我们每新建一个文件（可能是类也可能是接口）时编写的注释，我通常设定为：

Java代码

1./*

2. * created on ${date}

3. */

“Types”代表的是我们新建的接口或类前的注释，我通常设定为：

Java代码

1./**

2. *

3. * @author ${user}

4. */

第一行为一个空行，是用于你写该类的注释。如果你采用“职责驱动设计”，这里首先应当描述的是该类的职责。如果需要，你可以写该类一些重要的方法及其用法、该类的属性及其中文含义等。

${user}代表的是你在windows中登陆的用户名。如果这个用户名不是你的名称，你可以直接写死为你自己的名称。

其它我通常都保持为默认值。通过以上设定，你在创建类或接口的时候，

系统将自动为你编写好注释，然后你可以在这个基础上进行修改，大大提高注释编写的效率。

同时，如果你在代码中新增了一个函数时，通过Alt+Shift+J快捷键，可以按照模板快速添加注释。

2.可维护性

软件的可维护性有几层意思，首先的意思就是能够适应软件在部署和使用

中的各种情况。从这个角度上来说，它对我们的软件提出的要求就是不能将代码写死。

1）代码不能写死

应该通过定义一些常量或者通过一个属性文件可以修改，也不要把所有变

量都定义在一个地方，对于一些有限制的属性，定义成int或string是非常难维护的并且不容易在编译期检查到错误，java5开始提供了枚举这种数据类型，我们要善于利用。

据一个例子，baseLine.setStatus("3"); 不可读，一旦状态发生变化，

需要各处去改，用IDE无法重构，维护性很差，而且容易错。在hibernate中有@Enumerated可以直接用来映射，可读性，可维护性会好很多，而且可以避免用户输入了乱七八糟的字符。同样的例子还有phase这个属性。后面在Constants 中定义了一些变量提高了可读性，但是同样要求调用者对用哪个Constants的变量很清楚，并且不能约束调用者必须要用，不能提供约束。

2）预测可能发生的变化

除此之外，在设计的时候，如果将一些关键参数放到配置文件中，可以为软件部署和使用带来更多的灵活性。要做到这一点，要求我们在软件设计时，应当更多地有更多的意识，考虑到软件应用中可能发生的变化。

软件的可维护性的另一层意思就是软件的设计便于日后的变更。这一层意思与软件的可变更性是重合的。所有的软件设计理论的发展，都是从软件的可变更性这一要求逐渐展开的，它成为了软件设计理论的核心。

但是在这里还要提醒的一点就是过度设计带来的问题，如果我们在设计任何功能时都考虑以后会不会有变化，然后去设计一个框架去适应这些变化，那么可能把一些简单的问题给复杂化了，因为实现一个功能和实现一个框架，然后基于这个框架实现这个功能在工作量上是有天壤之别的。这个就需要对需求要有充分的了解，并且根据经验取得平衡。大多数情况下直接实现功能，在必要的时候进行重构是比较好的方法。但如果没有持续重构的保证，走一步看一步会把代码写得乱七八糟。

3.可变更性

前面我提到了，软件的变更性是所有软件理论的核心，那么什么是软件的可变更性呢？按照现在的软件理论，客户对软件的需求时时刻刻在发生着变化。当软件设计好以后，为应对客户需求的变更而进行的代码修改，其所需要付出的代价，就是软件设计的可变更性。由于软件合理地设计，修改所付出的代价越小，则软件的可变更性越好，即代码设计的质量越高。一种非常理想的状态是，无论客户需求怎样变化，软件只需进行适当地修改就能够适应。但这之所以称之为理想状态，因为客户需求变化是有大有小的。如果客户需求变化非常大，即使再好的设计也无法应付，甚至重新开发。然而，客户需求的适当变化，一个合理地设计可以使得变更代价最小化，延续我们设计的软件的生命力。

1）通过提高代码复用提高可变更性

我们对于各数据项的操作在各个模块的代码中都可以看到，甚至有些还写入到了那些复杂的SQL语句中。在这样一种情况下，如果对数据项的命名、分类等逻辑进行修改无异于需要遍历这个项目代码。代码复用的道理十分简单，但要具体运作起来非常复杂，它除了需要很好的代码规划，还需要持续地代码重构。

对整个系统的整体分析与合理规划可以根本地保证代码复用。系统分析师通过用例模型、领域模型、分析模型的一步一步分析，最后通过正向工程，生成系统需要设计的各种类及其各自的属性和方法。采用这种方法，功能被合理地划分到这个类中，可以很好地保证代码复用。

采用以上方法虽然好，但技术难度较高，需要有高深的系统分析师，并不是所有项目都能普遍采用的，特别是时间比较紧张的项目。通过开发人员在设计过程中的重构，也许更加实用。当某个开发人员在开发一段代码时，发现该功能与前面已经开发功能相同，或者部分相同。这时，这个开发人员可以对前面已经

开发的功能进行重构，将可以通用的代码提取出来，进行相应地改造，使其具有一定的通用性，便于各个地方可以使用。

一些比较成功的项目组会指定一个专门管理通用代码的人，负责收集和整理项目组中各个成员编写的，可以通用的代码。这个负责人同时也应当具有一定的代码编写功力，因为将专用代码提升为通用代码，或者以前使用该通用代码的某个功能，由于业务变更，而对这个通用代码的变更要求，都对这个负责人提出了很高的能力要求。

虽然后一种方式非常实用，但是它有些亡羊补牢的味道，不能从整体上对项目代码进行有效规划。正因为两种方法各有利弊，因此在项目中应当配合使用。

2）职责驱动设计

前面我提到，当我们尝试写一些复杂功能的时候，我们把功能分解成一个个相对独立的函数。但是，应当将这些函数分配到哪个类中呢？也就是系统中的所有类都应当拥有哪些函数呢？或者说应当表现出哪些行为呢？答案就在这里：以职责为中心，根据职责分配行为。我们在分析系统时，首先是根据客户需求进行用例分析，然后根据用例绘制领域模式和分析模型，整个系统最主要的类就形成了。通过以上分析形成的类，往往和现实世界的对象是对应的。正因为如此，软件世界的这些类也具有了与现实世界的对象相对应的职责，以及在这些职责范围内的行为。

职责驱动设计的核心思想，就是我们在对一个系统进行分析设计的时候，应当以职责为中心，根据职责分配行为。这种思想首先要求我们设计的所有软件世界的对象，应当与现实世界尽量保持一致，称为“低表示差异”。有了低表示差异，一方面提高了代码的可读性，另一方面，当业务发生变更的时候，也可以根据实际情况快速应对变更。

a.代码设计的目标：低耦合，高内聚

耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。耦合包括：1．元素B是元素A的属性，或者元素A引用了元素B的实例（这包括元素A调用的某个方法，其参数中包含元素B）。

2．元素A调用了元素B的方法。

3．元素A直接或间接成为元素B的子类。

4．元素A是接口B的实现。

如果一个元素过于依赖其它元素，一旦它所依赖的元素不存在，或者发生变更，则该元素将不能再正常运行，或者不得不相应地进行变更。因此，耦合将大大影响代码的通用性和可变更性。

内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性。内聚就像一个

管理者，它只做自己职责范围内的事，而将其它与它相关的事情，分配给别人去做。

高质量的代码要求我们的代码保持低耦合、高内聚。但是，这个要求是如此的抽象与模糊，如何才能做到这些呢？软件大师们告诉我们了许多方法，其中之一就是职责驱动设计。要理解职责驱动设计，我们首先要理解“低表示差异”。

b.低表示差异

我们开发的应用软件实际上是对现实世界的模拟，因此，软件世界与现实世界存在着必然的联系。如果我们在软件分析和设计的过程中，将软件世界与现实世界紧密地联系到一起，我们的软件将更加本色地还原事物最本质的规律。这样的设计，就称之为“低表示差异”。

采用“低表示差异”进行软件设计，现实世界有什么事物，就映射为软件世界的各种对象（类）；现实世界的事物拥有什么样的职责，在软件世界里的对象就拥有什么样的职责；在现实世界中的事物，因为它的职责而产生的行为，在软件世界中就反映为对象所拥有的函数。

低表示差异，使分析设计者对软件的分析和设计更加简单，思路更加清晰；使代码更加可读，阅读者更加易于理解；更重要的是，当需求发生变更，或者业

务产生扩展时，设计者只需要遵循事物本来的面貌去思考和修改软件，使软件更加易于变更和扩展。

c.角色、职责、协作

理解了“低表示差异”，现在我们来看看我们应当如何运用职责驱动设计进行分析和设计。首先，我们通过与客户的沟通和对业务需求的了解，从中提取出现实世界中的关键事物以及相互之间的关系。这个过程我们通常通过建立领域模型来完成。领域模型建立起来以后，通过诸如Rational Rose这样的设计软件的正向工程，生成了我们在软件系统中最初始的软件类。这些软件类，由于每个都扮演着现实世界中的一个具体的角色，因而赋予了各自的职责。前面我已经提到，如果你的系统采用职责驱动设计的思想进行设计开发，作为一个好的习惯，你应当在每一个软件类的注释首行，清楚地描述该软件类的职责。

当我们完成了系统中软件类的制订，分配好了各自的职责，我们就应该开始根据软件需求，编写各个软件类的功能。在前面我给大家提出了一个建议，就是不要在一个函数中编写大段的代码。编写大段的代码，通常会降低代码的内聚度，因为这些代码中将包含不是该软件类应当完成的工作。作为一个有经验的开发人员，在编写一个功能时，首先应当对功能进行分解。一段稍微复杂的功能，通常都可以被分解成一个个相对独立的步骤。步骤与步骤之间存在着交互，那就是数据的输入输出。通过以上的分解，每一个步骤将形成一个独立的函数，并且使用一个可以表明这个步骤意图的释义函数名。接下来，我们应当考虑的，就是应当将这些函数交给谁。它们有可能交给原软件类，也有可能交给其它软件类，其分配的原则是什么呢？答案是否清楚，那就是职责。每个软件类代表现实世界的一个事物，或者说一个角色。在现实世界中这个任务应当由谁来完成，那么在软件世界中，这个函数就应当分配给相应的那个软件类。

通过以上步骤的分解，一个功能就分配给了多个软件类，相互协作地完成这个功能。这样的分析和设计，其代码一定是高内聚的和高可读性的。同时，当需求发生变更的时候，设计者通过对现实世界的理解，可以非常轻松地找到那个需要修改的软件类，而不会影响其它类，因而也就变得易维护、易变更和低耦合了。

举一个实例也许更能帮助理解。拿一个员工工资系统来说吧。当人力资源发放一个月工资的时候，以及离职的员工肯定不能再发放工资了。在系统设计的期初，开发人员商量好，在员工信息中设定一个“离职标志”字段。编写工资发放的开发人员通过查询，将“离职标志”为false的员工查询出来，并为他们计算和发放工资。但是，随着这个系统的不断使用，编写员工管理的开发人员发现，“离职标志”字段已经不能满足客户的需求，因而将“离职标志”字段废弃，并增加了一个“离职时间”字段来管理离职的员工。然而，编写工资发放的开发人员并不知道这样的变更，依然使用着“离职标志”字段。显然，这样的结果就是，软件系统开始对离职员工发放工资了。仔细分析这个问题的原因，我们不难发现，确认员工是否离职，并不是“发放工资”软件类应当完成的工作，而

应当是“员工管理”软件类应当完成的。如果将“获取非离职员工”的任务交给“员工管理”类，而“发放工资”软件类仅仅只是去调用，那么离职功能由“离职标志”字段改为了“离职时间”字段，其实就与“发放工资”软件类毫无关系。而作为“员工管理”的开发人员，一旦发生这样的变更，他当然知道去修改自己相应的“获取非离职员工”函数，这样就不会发生以上问题。

在aside中，同样存在很多类似的问题，我们每个模块对外暴露的接口基本上就是对数据库的操作接口，而没有按照业务逻辑进行封装隐藏，一个模块的数据模型的变化往往导致很多模块的变更。比如任务模块、基线模块、走查模块这些通用模块，应该从较高层次上总结出对其他模块的服务接口，其他模块要避免直接操作这些模块的数据。我们系统中更多的情况是大家害怕这种变更，不改变以前的逻辑，通过一些奇怪的方法加上新的逻辑，导致代码的可读性和可维护性越来越差。

d.职责分配与信息专家

通过以上对职责驱动设计的讲述，我们不难发现，职责驱动设计的精要就

是职责分配。但是，在纷繁复杂的软件设计中，如何进行职责分配常常令我们迷惑。

信息专家模式（又称为专家模式）告诉我们，在分析设计中，应当将职责

分配给软件系统中的这样一个软件类，它拥有实现这个职责所必须的信息。我们称这个软件类，叫“信息专家”。用更加简短的话说，就是将职责分配给信息专家。

为什么我们要将职责分配给信息专家呢？我们用上面的例子来说明吧。当“发放工资”软件类需要获取非离职员工时，“员工管理”软件类就是“获取非离职员工”任务的信息专家，因为它掌握着所有员工的信息。假设我们不将“获取非离职员工”的任务交给“员工管理”软件类，而是另一个软件类X，那么，为了获取员工信息，软件类X不得不访问“员工管理”软件类，从而使“发放

工资”与X耦合，X又与“员工管理”耦合。这样的设计，不如直接将“获取

非离职员工”的任务交给“员工管理”软件类，使得“发放工资”仅仅与“员工管理”耦合，从而有效地降低了系统的整体耦合度。

不应该把大量的逻辑充斥在Action中，应该把逻辑集中在service层，action只应该充当接收页面请求，请求服务，准备下个页面的显示数据，然后返回结果。比如SystemRequirementAction. baseline()函数完全应该是baseline模块提供的服务，提供接口给各模块使用，而不应该放在SystemRequirementAction中做，在baseline模块，应该提供一个统一的manager，而不是三个分开的其实只是封装了数据操作的manager，BaseLineManager、BaseLineSourceManager、BaseLineTargetManager，这三个manager本质上不能称之为service。

总之，采用“职责驱动设计”的思路，为我们提高软件开发质量、可读性、可维护性，以及保持软件的持续发展，提供了一个广阔的空间。

3）利用设计模式提高可变更性

一个快速提高软件质量的捷径就是利用设计模式。这里说的设计模式，不仅仅指经典的模式，是一切前人总结的，我们可以利用的、更加广泛的设计模式。

a.警惕if...else...

我忘了是从哪里学到的这个原则，但这个简单的原则一直非常有用地指导我的编码，它是这样描述的：当你发现你必须要设计这样的代码：“if...elseif...elseif...else...”时，你应当想到你的代码应当重构一下了。我们先看看这样的代码有怎样的特点。

Java代码

if(var.equals("A")){

doA();

}else if(var.equals("B")){

doB();

}else if(var.equals("C")){

doC();

}else{

doD();

}

这样的代码很常见，也非常平常，我们大家都写过。但正是这样平常才隐藏着我们永远没有注意的问题。问题就在于，如果某一天这个选项不再仅仅是A、B、C，而是增加了新的选项，会怎样呢？你也许会说，那没有关系，我把代码改改就行。然而事实上并非如此，在大型软件研发与维护中有一个原则，每次的变更尽量不要去修改原有的代码。如果我们重构一下，能保证不修改原有代码，仅仅增加新的代码就能应付选项的增加，这就增加了这段代码的可维护性和可变更性，提高了代码质量。那么，我们应当如何去做呢？

经过深入分析你会发现，这里存在一个对应关系，即A对应doA()，B对应doB()．．．如果将doA()、doB()、doC()．．．与原有代码解耦，问题就解决了。如何解耦呢？设计一个接口X以及它的实现A、B、C．．．每个类都包含一个方法doX()，并且将doA()的代码放到A.doX()中，将doB()的代码放到B.doX()中．．．经过以上的重构，代码还是这些代码，效果却完全不一样了。我们只需要这样写：

Java代码

X x = factory.getBean(var);

x.doX();

这样就可以实现以上的功能了。我们看到这里有一个工厂，放着所有的A、B、C．．．并且与它们的key对应起来，并且写在配置文件中。如果出现新的选项时，通过修改配置文件就可以无限制的增加下去。

这个模式虽然有效提高了代码质量，但是不能滥用，并非只要出现if...else...就需要使用。由于它使用了工厂，一定程度上增加了代码复杂度，因此仅仅在选项较多，并且增加选项的可能性比较大的情况下才需要使用。一般来说，原则是第一次就这样写，当发生了两次需要增加选项的时候再去重构它。

在aside中，有很多这种if else的情况，前面我举的几个大函数的例子就是因为里面有大量的if else，可以用这种方法重构一下

b.策略模式

也许你看过策略模式的相关资料但没有留下太多的印象。一个简单的例子可以让你快速理解它。如果一个员工系统中，员工被分为临时工和正式工并且在不同的地方相应的行为不一样。在设计它们的时候，你肯定设计一个抽象的员工类，并且设计两个继承类：临时工和正式工。这样，通过下塑类型，可以在不同的地方表现出临时工和正式工的各自行为。在另一个系统中，员工被分为了销售人员、技术人员、管理人员并且也在不同的地方相应的行为不一样。同样，我们在设计时也是设计一个抽象的员工类，并且设计数个继承类：销售人员、技术人员、管理人员。现在，我们要把这两个系统合并起来，也就是说，在新的系统中，员工既被分为临时工和正式工，又被分为了销售人员、技术人员、管理人员，这时候如何设计。如果我们还是使用以往的设计，我们将不得不设计很多继承类：销售临时工、销售正式工、技术临时工、技术正式工．．．如此的设计，在随着划分的类型，以及每种类型的选项的增多。通过以上一个系统的设计，我们不得不发现，我们以往学习的关于继承的设计遇到了挑战。

解决继承出现的问题，有一个最好的办法，就是采用策略模式。在这个应用中，员工之所以要分为临时工和正式工，无非是因为它们的一些行为不一样，比如，发工资时的计算方式不同。如果我们在设计时不将员工类分为临时工类和正式工类，而仅仅只有员工类，只是在类中增加“工资发放策略”。当我们创建员工对象时，根据员工的类型，将“工资发放策略”设定为“临时工策略”或“正式工策略”，在计算工资时，只需要调用策略类中的“计算工资”方法，其行为的表现，也设计临时工类和正式工类是一样的。同样的设计可以放到销售人员策略、技术人员策略、管理人员策略中。一个通常的设计是，我们将某一个影响更大的、或者选项更少的属性设计成继承类，而将其它属性设计成策略类，就可以很好的解决以上问题。

使用策略模式，你同样把代码写活了，因为你可以无限制地增加策略。但是，使用策略模式你同样需要设计一个工厂——策略工厂。以上实例中，你需要设计一个发放工资策略工厂，并且在工厂中将“临时工”与“临时工策略”对应起来，将“正式工”与“正式工策略”对应起来。

c.适配器模式

水货手机充电器的插头与我们常用的插座不一样，必须带一个适配器，才能使用不同地方的插座。这是一个对适配器模式最经典的描述。当我们设计的系统要与其它系统交互，或者我们设计的模块要与其它模块交互时，这种交互可能是调用一个接口，或者交换一段数据，接受方常常因发送方对协议的变更而频繁变更。这种变更，可能是接受方来源的变更，比如原来是A系统，现在变成B系统了；也可能是接受方自身的代码变更，如原来的接口现在增加了一个参数。由于发送方的变更常常导致接受方代码的不稳定，即频繁跟着修改，为接受方的维护带来困难。

遇到这样的问题，一个有经验的程序员马上想到的就是采用适配器模式。在设计时，我方的接口按照某个协议编写，并且保持固定不变。然后，在与真正对方接口时，在前段设计一个适配器类，一旦对方协议发生变更，我可以换个适配器，将新协议转换成原协议，问题就解决了。适配器模式应当包含一个接口和它的实现类。接口应当包含一个本系统要调用的方法，而它的实现类分别是与A系统接口的适配器、与B系统接口的适配器．．．

我曾经在一个项目中需要与另一个系统接口，起初那个系统通过一个数据集的方式为我提供数据，我写了一个接收数据集的适配器；后来改为用一个XML 数据流的形式，我又写了一个接收XML的适配器。虽然为我提供数据的方式不同，但是经过适配器转换后，输出的数据是一样的。通过在spring中的配置，我可以灵活地切换到底是使用哪个适配器。

d.模板模式

经典模式中的模板模式，对开发者的代码规划能力提出了更高的要求，它要求开发者对自己开发的所有代码有一个相互联系和从中抽象的能力，从各个不同的模块和各个不同的功能中，抽象出其过程比较一致的通用流程，最终形成模板。譬如说，在aside中，高层需求、底层需求、编写测试用例等流程，虽然涉及的数据项不同，但是都要经过分配编写任务、走查、提交问题、评审等流程。正因为有这样的特征，它们可以使用共同的模板，那么，什么是模板模式呢？

模板模式（Template Model）通常有一个抽象类。在这个抽象类中，通常有一个主函数，按照一定地顺序去调用其它函数。而其它函数往往是某这个连续过程中的各个步骤。由于这是一个抽象类，这些步骤函数可以是抽象函数。抽象类仅仅定义了整个过程的执行顺序，以及一些可以通用的步骤（如读取XML文件和解析XML数据流），而另一些比较个性的步骤，则由它的继承类自己去完成。

各个继承类可以根据自己的需要，通过重载重新定义各个步骤函数。但是，模板模式要求不能重载主函数，因此正规的模板模式其主函数应当是final（虽然我们常常不这么写）。另外，模板模式还允许你定义的这个步骤中，有些步骤是可选步骤。对与可选步骤，我们通常称为“钩子（hook）”。它在编写时，在

抽象类中并不是一个抽象函数，但却是一个什么都不写的空函数。继承类在编写时，如果需要这个步骤则重载这个函数，否则就什么也不写，进而在执行的时候也如同什么都没有执行。

通过以上对模板模式的描述可以发现，模板模式可以大大地提高我们的代码复用程度。

以上一些常用设计模式，都能使我们快速提高代码质量。还是那句话，设计模式不是什么高深的东西，恰恰相反，它是初学者快速提高的捷径。