误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体 参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。

 

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好 心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培 训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

 

    误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系 。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不 一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。 

 

    误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味 工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对“成就感”的追求，应该向每一个人详细描述最终“ 作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作 效率。

 

    误区10：为了保证项目继续，为了留住核心程序员，加薪吧。分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了——加薪的 人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。 既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形 成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水 ，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其 感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

 

    做一名系统分析师，要首先认识什么是系统分析师。对于同样一件事物的认识，每个人都会不一样，“一千个人有一千个哈姆雷特”，这关乎到认识论。其实,一个人的认识正好折射出了他的经验、水平、层次、能力。一句话，大道由简，我们也许熟悉了很多系统分析方面的技术，然后我们需要问自己是不是真的懂这个职业的本质含义所在，一定不要舍本求末。

    上面的定义很简单，但反映了一些基本的要素。系统分析师首先是商业人员，然后才是IT技术人员，但系统分析师不是程序员，他的使命是解决业务问题，手段是信息技术。他不但要理解还要会详细地说明，这意味着他的商业知识、理解分析能力以及表达能力是比较基础的核心能力。还有, 系统分析最重要的是实践过程。系统分析师最好和业务人员打成一片,这样才会获得用户的信任。

   顺便需要说明的是，信息系统有很多种类型,常见的有OLTP、 MIS、EIS、DSS。当然,你还可以谈很多,其实，任何一个名词都足够写一本书,你就大胆地讲出你的理解吧。但一定要记得总结,用一句话能总结出来就不用两句话,系统分析这个职位对思维的清晰要求颇高。

 

    首先，系统分析师应熟悉如何建立信息系统，这要求相当高的信息技术能力，包括软件工程、主流技术架构、网络、数据库技术等等。

    第二,系统分析师应必须熟悉自己正为之工作的商业行业，以及该行业如何使用各种类型系统的情况。

    最后，系统分析师应需要熟悉相当多的人及其工作方式，因为这些人是信息系统的使用者，或者说是系统分析师的“客户”。

    系统分析师是“通才”，正是因为他们连接了IT和业务。优秀的分析师其实懂三种“世界”的语言，即计算机语言、商业语言、人的语言。

    对于商业，有些分析师一生专门研究一个特定的商业行业，比如制造业、零售业、服务业或贸易行业。一个非常熟悉某特定行业的分析师能够为这个行业的公司解决一些复杂的问题。

    熟悉这个公司则需要花费一些时间，尤其是细节方面，包括组织结构、使命、成功的因素、战略和计划、企业文化和企业价值。

    总之,系统分析师=行业业务专家+IT技术专家+管理专家。

 

三、系统分析师解决问题的大致过程是什么？

系统分析师解决问题的大致过程一般如下：

（1）研究和理解问题。

（2）核实解决问题的效益大于成本。

（3）确定解决问题的需求。

（4）制定一套可能的解决方案，提供多种可供选择的方法。

（5）决定最佳方案并推荐给决策层。

（6）详细说明所选方案的细节。

（7）实施解决方案。

（8）监控结果是否达到预期结果。

这个是经过归纳的大致过程,实际还有其他经典的过程,与之的区别只是形式上不同，但求解问题的过程是一致的。

上面的步骤是经过归纳过的，也许不同类型的系统，不同类型的企业工作方法不尽相同，但从宏观的角度看的确是类似的。

 

四、系统分析原型法的意义

    原型(Prototype) 即样品、模型的意思。把系统主要功能和接口通过快速开发制作为“软件样品 ”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。另外，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。

    对原型的基本要求包括：体现主要的功能、提供基本的界面风格、展示比较模糊的部分以便于确认或进一步明确。原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。

    原型法意义在于可视化、强化沟通、降低风险、节省后期变更成本、提高项目成功率。一般来说，采用原型法后可以改进需求质量。虽然投入了较多先期的时间，但可以显著减少后期变更的时间。原型法投入的人力成本代价并不大，但可以节省后期成本。对于较大型的软件项目来说，原型系统可以成为开发团队的蓝图。另外，原型通过充分和客户交流，还可以提高客户满意度。

    原型法是在计算机技术发展到一定阶段，用户应用需求高涨的情况下发展的一种方法论，但它同时又是对开发人员有高要求的一种方法论。

原型法的基本思想如下: 原型法是确定需求策略，是对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。原型法实际上是一种动态定义技术。

　　原型法被认为对于大多数企业的业务处理来说，需求定义几乎总能通过建立目标系统的工作模型来很好地完成，而且这种方法和严格定义方法比较起来，成功可能性更大。

 

原型法开发策略基于如下的假设：

　（1）并非所有的需求在系统开发以前都能准确地说明。

　（2）有快速的系统建造工具。

　（3）项目参加者之间通常都存在通信上的障碍。

　（4）需要实际的、可供用户参与的系统模型(system model)。

    文字和静态图形是一种比较好的通信工具，然而其最大的缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统，其差别是十分显著的。因此，当能够提供一个生动的规格说明成为可能的话，人们就不会满足于一个静止的、被动的规格说明。

　　总之，当提供一个活生生的系统模型时，人们对它的了解将比说明性材料好得多。 　
　（5）需求一旦确定，就可以遵从严格的方法。

　（6）大量的反复是不可避免的、必要的，应该加以鼓励。

 

在信息系统设计的过程中，常用的各种不同形式的部分原型有：
　（1） 对话原型

　　原型模拟预期的终端交互，使用户可以从屏幕上查看他们将接收什么、进行的操作，并提出遗漏之处，从而加深正确的理解。终端对话的设计效果直接影响着系统的可用性和用户对系统的接受程度。

　（2） 数据输入原型

建立数据输入的原型，可以检查数据的输入速度和正确性，还能进行有效性和完整性的检查。

　（3） 报表系统原型

提供给用户的各种报告应在整个系统实现之前给用户看，报表子系统需要经常进行大量修改以满足系统的需要，因此，可以把报表生成器作为原型。

　（4） 数据系统原型

　　首先生成一个含有少量记录的原型数据库，这样用户和分析师与它可以进行交互，生成报表和显示有用信息。这种交互经常导致产生对不同的数据类型、新的数据域或不同的数据组织方式的需求，还可以在原型化工具的帮助下探索用户将如何使用信息以及数据库是什么样的。

　（5） 计算和逻辑原型

　　有时一个应用逻辑或计算是复杂的。审计员、工程师、投资分析师和其他用户可以使用高级程序设计语言建立他们所需的计算实例。这些实例可以组合在一起构成一个大的系统，与其它应用系统、数据库或终端相连接，用户可以使用这些计算原型检验他们所求结果的准确性。

　（6） 应用程序包原型

    在一个应用程序包和其它应用系统相连或实际使用之前，可以通过一个小组用户来鉴定这个应用程序包是否令他们满意，若不满意可以进行大量的修改，直到令他们满意。

　（7） 概念原型
    原型法是近年来流行的软件需求捕获方法之一。我们应该明白原型法是手段而不是目的。需要回答的要点是,原型法的背景、概念、定义、意义、如何实现原型、最好能够举例说明。

    能够回答这些问题才能说明你完全掌握了原型法。很显然,提出这种问题的企业对这种方法在实际工作中是会相当倚重的，因此您不仅要知之还要行之。

    以一个简单的案例来说明，王五是某家大型电子商务贸易公司的系统分析师,他负责做了一个询盘系统。由于询盘系统牵涉到许多抽象专业知识,因此为了便于沟通,王五经过一番研究制作了界面原型设计,并给出了解决方案,领导和客户看了原型设计后通过该需求方案。这个案例说明,今天的需求分析,不再是分析师和客户之间的访谈,更是一种通过实际原型(模型)互相启发,从而发现需求,归纳总结需求的一个实践过程。但我们可以看到,原型法只是一种手段,与用户良好的互动和沟通是获得需求的基本点所在.

 

六、如何进行有效的需求开发过程?
    需求描述了客户需要或目标,或者描述了为满足这种需要或目标，产品必须具有的条件或能力,它是种特性,要求产品为涉众提供价值。

    系统需求是系统必须完成的功能和局限性。功能需求是描述系统必须完成的活动或过程的一种系统需求,它就是系统要投入的商业应用。用户需求(User Requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（Use Case）文档或方案脚本（Scenario）说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。而所谓特性(Feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
    系统分析阶段的活动则有如下几种（表1）,同时列举了其对应解决相应的关键问题。

 

表1

分析阶段的活动
关键问题

收集信息 是否已经拥有了全部的信息来定义系统所必须完成的工作？
定义系统需求 需要系统做什么？
构建可行性的发现原型 可以证明此种技术能够实现想让它完成的那些功能吗？
是否已经构建出一些原型让用户能够完全理解新系统的潜在功能？

产生评估方案 创建系统的最好方案是什么？
与管理部门一起复查各种建议 是否应该继续设计和实现我们提出的系统？

 

解决关键问题的方法，大致如下：

（1） 搞清楚系统相关者,通过组织结构图找系统角色,他们是系统的主要使用力量。

（2） 系统开发的分析阶段的目标是理解商业功能和获得系统需求。

（3） 在改正旧系统到新系统的转换过程中，关键是新系统。通过调查问卷，面谈去理解新系统的限制。通过复查现有文档，去理解信息的过程。通过研究商业过程和供应商，去理解新系统的功能。最终是为新系统开发出系统需求和模型。

以上的描述是一种系统分析的流程,下面介绍从需求角度看分析师的业务问题。

需求开发依先后顺序可以分为：需求获取（Elicitation）、分析(Analysis)、编写规格说明（Specification）和验证（Verification）四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。

需求开发活动包括以下几个方面：

（1） 确定产品所期望的用户类。

（2）获取每个用户类的需求。

（3） 了解实际用户任务和目标以及这些任务所支持的业务需求。

（4）分析源于用户的信息，以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

（5）将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

（6）了解相关质量属性的重要性。

（7）商讨实施优先级的划分。

（8）将所收集的用户需求编写成规格说明和模型。

（9）评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都要弄清楚。

    需求分析（Requirement Analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析的目的在于开发出高质量的需求，这样你能做出实用的项目估算并可以进行设计、构造和测试。

    通常把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆，并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。下面是需求分析中经常使用的方法:

（1）绘制系统上下文示意图

这种示意图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

（2）创建用户接口原型

当开发人员或用户不能确定需求时，开发一个用户接口原型———个局部的可能实现——这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间的所有冲突之处。

（3）分析需求可行性

在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

（4）确定需求的优先级别

应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

（5）为需求建立模型

需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系，以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

（6）创建数据字典

数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

（7）使用质量功能调配

质量功能调配(Quality Function Deployment，QFD）是一种高级系统技术，它将产品特性、属性与对用户价值联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

    系统分析师需要掌握需求捕获、需求分析和需求确认方法,并且要有一定的实践经验,因为需求分析是门需要实践的学问。

    需求捕获的方法其实有多种,你可以熟悉每一种方法。通过文档概要、面谈、观察、原型、调查表、供应商调查、联合应用会议等等方法是可以获得需求的。但在实际中,你不必十八般武艺样样都要使出来, 本质上持续不断的捕获高质量的需求的方法只有一个，就是和业务人员打成一片,这样,不再是你去找需求,需求可能会来找你了,这是一种主动需求的方法,所以系统分析师一般都需要有良好的人际互动能力。

    当然,需求捕获还是有其自身的方法的, 要讲需求捕获必先谈到收集信息, 信息不足则“巧妇难为无米之炊”。其实这里有三个经典的问题,会是系统分析师经常用到的或提到的问题。由信息收集到需求捕获，再到需求分析是需求开发的中轴线,而能否收集到必要的有效的需求信息, 请仔细体会如下三个问题。

（1）商业过程和操作是什么，即你要干什么

系统分析师核心是理解商业过程,一般用户只会对现状回答,但分析师要能识别在改进的系统中哪些要保留，哪些要删除。这个问题是沟通的第一步,回想当年笔者第一次就这样问用户：“你的流程是什么？你有什么问题”,何其愚也,从问用户的问题可以看出这个分析师是不是有经验。

（2 ）商业过程应该怎样完成，即系统分析师该如何完成它,或者说需要哪些步骤

用户谈的是老系统的完成办法,而系统分析师的核心是新系统应该如何支持这项功能,而不是在现有系统下如何执行。分析师重要的是超越现在,使新技术带来的商业处理方法更高效。
（３）需要什么样的信息，即为了完成商业过程，系统分析师要使用哪些信息，使用什么样的表单或报告。

有价值的系统分析师有一套需求捕获的手法，有价值的系统分析师一定会从理论到实际仔细研究需求分析的过程。

 

 

 

 

 

HTML中几个Tag比较有用，平时大家用得比较少，而且是符合W3C XHTML标准的。

1. Label

Label是用来标记Input元素的提示的。例如：
<label for="id_name">Name</label><br />
<input type="text" name="name" id="id_name" size="20"/>

Label的“For”属性要和Input元素的ID相一致。

好处：点击提示文字，就自动Focus对应的输入元素。对于Radio，Checkbox这类点击区域特别小的控件特别有用：

Color:<br />
<input type="checkbox" name="color" id="color_r" value="red"><label for="color_r"> red</label><br />
<input type="checkbox" name="color" id="color_g" value="green"><label for="color_g"> green</label><br />
<input type="checkbox" name="color" id="color_b" value="blue"><label for="color_x"> blue</label><br />
<!--如果For和ID不匹配，点击文字是没有用的-->

 

2. FieldSet & Legend

      FieldSet用来明确把一组Input控件归成一组（相当于VB/VC里面的Group控件），而Legend则是组的标题(相当于Group控件的标题)。 例如：

<fieldset style="width:20%">
<legend>Person</legend>
<label for="name">Name</label><input type="text" id="name" />
<fieldset>
<legend>Gender</legend>
<input type="radio" name="gender" id="male" /><label for="male">Male</label><br>
<input type="radio" name="gender" id="female" /><label for="female">Female</label>
</fieldset>

 

意图：一个类适配了多个版本的组件、类库、API或其它实体。为组件、类库、API或其它实体的每个版本提取一个Adapter。

 

动机：对于所需要支持的东西的每一个版本，创建一个单独的类。这个类名甚至可以包含它所支持的版本号，以便于显示地指出它所支持地版本。这些类就是Adapter。Adapter可以使客户代码很容易地从类库或API的一个版本转入另一个版本。并且，程序员通常依赖于运行时信息，使用正确的Adapter来配置他们的程序。

 

优点与缺点：

＋隔离了不同版本组件、类库或API之间的不同之处。

＋使类只负责适配代码的一个版本。

＋避免频繁地修改代码。

－如果某个重要的行为在Adapter中不可用的话，那么客户代码将无法执行这一重要行为。

 

做法：

1、识别出负担过重的适配器，即适配了太多版本的类。

2、针对负担过重的适配器所支持的多个版本中的一个版本，应用提炼子类重构或提炼类重构，产生一个新的适配器。把只用于这个版本的实例变量和方法复制或搬移到新的适配器中。

3、重复步骤2直到负担过重的适配器重不再含有版本为止。

4、应用上移方法和形成Template Method之类的重构，去除新适配器中的重复代码。

 

意图：客户代码与两个类交互，其中的一个类具有首选的接口。用一个Adapter统一接口。

 

动机：当代码原本可以通过统一的接口与不同的类交互，而出于某种原因，实际代码并非如此的时候，坏味异曲同工的类就出现了，解决这种问题的一个简单的方法是重命名或搬移方法，直到接口相同。如果无法实现这种改动，就可能需要考虑实现一个Adapter了。

 

优点和缺点：

＋使客户代码可以通过相同的接口与不同的类交互，从而去除或减少了重复代码。

＋使客户代码可以通过公共的接口与多个对象交互，从而简化了客户代码。

＋统一了客户代码与不同的类的交互方式。

－当类的接口可以改变的时候，会增加设计的复杂度。

 

做法：

1、客户代码更愿意使用一个类的接口，而不是另一个，而且，客户代码希望可以通过一个公共的接口与两个类交互。在具有客户代码首选接口的类上应用提炼接口重构，生成一个公共接口。更新这个类中所有接收自身类型为参数的方法，使其参数类型变为这个公共接口。

2、在使用被适配者的客户类中，应用提炼类重构产生一个原生适配器。

3、把客户类中所有类型为被适配者的字段、本地变量或参数的类型都更新为适配器。这包括被适配者的客户代码先从适配器获得被适配者的引用，然后再调用被适配者的方法。

4、对任何客户代码调用相同被适配者方法的地方，应用提炼方法重构，以便产生一个被适配者的调用方法。

5、在被适配者调用方法上应用搬移方法重构，把它从客户代码搬移到适配器中，客户代码中每处对这个被适配者方法的调用现在都应该通过这个适配器。

6、更新适配器，使其正式地“实现”这个公共接口。

7、更新客户代码，把所有类型为适配器地字段、本地变量和参数都改为使用公共接口类型。

 

意图：子类通过硬编码来通知另一个类的一个实例。去除这些子类，并使其超类能够通知一个或多个实现了Observer接口的类。

 

动机：Observer模式的每次实现都会产生一个主题（作为通知源的类）与其观察者之间的松耦合。Observer接口使这种松耦合成为可能。想要接收新信息的通知，类只需实现Observer接口，并把自己注册到一个主题。当发生改变时，主题会根据它所包含的实现了Observer接口的实例的集合依次通知这些实例。

 

优点和缺点：

＋使主题及观察者访问松散耦合。

＋支持一个或多个观察者。

－当硬编码的通知已经足够的时候，会增加设计的复杂度。

－当出项串联通知的时候，会增加代码的复杂度。

－当观察者没有从它们的主题中被删除的时候，可能会造成内存泄漏。

 

做法：

1、如果一个通知者代表它的接收者执行定制的行为，而不是执行单纯的通知逻辑，应用搬移到通知者的接收者中。

2、在接收者上应用提炼接口重构，只选择被它的通知者调用的方法，产生观察者接口。如果其他通知者会调用不在观察者接口中的方法，把这些方法添加到观察者接口中，这样它就可以支持所有接收者了。

3、使每个接收者都实现观察者接口。然后，使每个通知者都只通过观察者接口与它的接收者交互。

4、选择一个通知者，在其通知方法上应用上移方法重构。这包含上移通知者的观察者接口引用，以及设置引用的代码。

5、更新每个通知者的观察者，使它们注册到主题并与其交互，而不是通知者，然后删除通知者。

6、重构这个主题，使它包含观察者的一个集合，而不是仅仅一个观察者。

 

意图：类使用不同的代码处理单一对象与多个对象。用Composite能够产生既可以处理单一对象又可以处理多个对象的代码。

 

动机：如果一个类含有两个几乎一样的方法，唯一的区别就是一个用来处理单一对象，一个用来处理对象的集合，那么一/多之分就出现了。

用Composite替换一/多之分可以去除重复代码，统一客户代码的调用，还支持对象树的处理。

 

优点和缺点：

＋去除与处理一个或多个对象相关联的重复代码。

＋提供了处理一个或多个对象的统一方法。

＋支持处理多个对象的更丰富的方法。

－可能会在Composite的构造过程中要求类型安全的运行时检查。

 

做法：

1、多对象方法接收一个集合作为参数。创建一个新类，使它的一个构造函数可以接收集合，并为集合定义访问方法。

2、对多对象方法中与集合相关的代码应用提炼方法重构。把提炼出来的方法声明为公共方法，然后，在提炼出来的方法上引用搬移方法重构，把它搬移到组合类中。3、多对象几乎和单一对象方法一摸一样了，主要的区别是，多对象方法会实例化组合类。

4、修改多方法对象方法，使其只包含一行代码：调用单一对象方法，并把组合类实例作为参数传递给这个方法。需要使组合类与单一对象方法中使用的类型共享相同的接口或超类。

5、因为多对象方法现在只包含一行代码，所以可以使用将方法内联化重构使其内联化。

6、对组合类应用封装集合重构。

 

意图：一个类层次结构中的多个子类实现了同一个Composite。提取一个实现该Composite的超类。

 

动机：在提炼超类重构中，如果两个或多个类拥有相似的特性，就应该把这些共有的特性搬移到一个超类中。当相似属性是一个Composite时，应该把它搬移到超类中去。

类层次结构中的子类往往会存储其他类的集合，并含有报告这些类信息的方法。当这些被存储的类恰好在同一个类层次结构中时，就很有可能需要通过重构到Composite去除大量的重复代码。

 

优点和缺点：

＋去除重复的类存储逻辑和类处理逻辑。

＋能够有效地表达类处理逻辑的可继承性。

 

做法：

1、创建一个组合，它是在重构之后会成为一个Composite的类。适当的命名这个类，使其能反映出它所存储的类的类型。

2、把每个含有子结点的类声明为组合类的子类。

3、在含有子结点的类中，找出这样的类处理方法，它在所有含有子结点的类中被完全复制或部分复制。

4、对含有子结点的类中其他的包含完全重复和部分重复代码的类处理方法重复步骤3。

5、检查每个含有子结点的类的每段客户代码，考虑现在是否可以通过组合类的结构与含有子结点的类交互。如果可以，就改为使用组合类接口。

 

 

意图：子类中的两个方法以相同的顺序执行相似的步骤，但是步骤并不完全相同。通过把这些步骤提取成具有相同签名的方法来泛化这两个方法，然后上移这些泛化方法，形成Template Method。

 

动机：Template Method“一次性实现了一个算法的不变部分，并将可变的行为留给子类来实现”。当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。通过把这些行为搬移到单一的地方，重构到Template Method可以帮助子类摆脱重复的不变的行为纠缠：超类中的方法中的泛化算法。

 

优点和缺点：

＋通过把不变行为搬移到超类，去除子类中的重复代码。

＋简化并有效的表达了一个通用算法的步骤。

＋允许子类很容易地定制一个算法。

－当为了生成算法，子类必须实现很多方法的时候，会增加设计的复杂度。

 

做法：

1、在一个类层次结构中，找到一个相似的方法。在相似的方法上应用组合方法重构，提取出同一方法。

2、应用上移方法重构，把同一方法上移到超类中。

3、为了为相似方法的每个版本产生相同的方法体，在每个唯一方法上应用重命名方法重构，直到每个子类中额相似方法相同为止。

4、如果相似方法在每个子类中还没有一个相同的签名，应用重命名方法重构产生这个签名。

5、在相似方法上应用上移方法重构，在超类中为每个唯一方法定义抽象方法。

 

意图：条件逻辑用来调度请求和执行操作。为每个动作创建一个Command。把这些Command存储在一个集合中，并用获取及执行Command的代码替换条件逻辑。

 

动机：许多系统都会收到、发送并处理请求。条件调度程序是一条条件语句，它用来执行请求的发送和处理。有些条件调度程序很适合它们要完成的任务，有些则并不适合。

适合任务的条件调度程序往往只是把少量的请求发送到少量的处理逻辑中。这种调度程序的代码往往可以在一屏内显示我们不需要滚动屏幕。

 

优点和缺点:

＋提供了用统一方法执行不同行为的简单机制。

＋允许在运行时改变所处理的请求，以及如何处理请求。

＋仅仅需要很少的代码实现。

－当条件调度程序已经足够的时候，会增加设计的复杂度。

 

做法：

1、在包含条件调度程序的类中找到处理请求的代码，在这段代码上应用提炼方法重构，直到产生执行该代码行为的执行方法为止。

2、重复步骤1，把所有剩余的请求处理代码提炼到各自的执行方法中。

3、在每个执行方法上应用提炼类重构，产生处理请求的具体命令。

4、定义一个命令，即声明了与每个具体命令相同的执行方法的接口或抽象类。

5、使每个具体命令都实现或继承这个命令，并用命令类型更新所有使用具体命令的客户代码。

6、在包含条件调度程序的类中，定义并组装一个命令映射，这个映射包含每个具体命令，并用唯一标识符作为主键，在运行时可以用这个主键获取命令。

7、在包含条件调度程序的类中，把调度程序请求的条件代码替换为获取正确的具体命令并调用其执行方法的代码。

 

意图：用原生表示法隐含地形成树结构。用Composite替换这个原生表示法。

 

动机：基于数据地隐含树，往往要忍受构造隐式树的代码与如何表示树的代码之间的耦合之苦。重构实现Composite可以解开这种耦合；然而，重构后的客户代码又会与Composite耦合在一起。有时，需要通过另外一个间接层来解耦合。这是就需要应用用Builder封装Composite重构。

 

优点和缺点：

＋封装重复的指令，如格式化、添加或删除结点。

＋提供了处理相似逻辑增长的一般性方法。

＋简化了客户代码的构造职责。

－当构造隐式树更简单的时候，会增加设计的复杂度。

 

做法：

1、识别隐式叶子，即隐式树中可以被建模为新类的部分。这个新类就是叶子结点。应用提炼类或类似重构创建这个新的叶子结点类，或者使用测试驱动开发－－针对具体情况，选择两者中更简单的方法。

2、用叶子结点的实例替换隐式叶子的每一次使用，这样，隐式树就不再依赖于隐式叶子而依赖于叶子结点了。

3、对隐式树中其他可以表示为隐式叶子的部分重复步骤1和步骤2。确保创建出的所有叶子结点都共享一个统一的接口。可以应用提炼超类重构或提炼接口重构来生成这个接口。

4、识别隐式双亲，即隐式树中作为隐式叶子双亲的部分。隐式双亲将要变具体情况，选择两者中更简单的那个方法。

5、用双亲结点的实例替换隐式双亲的每一次使用，并用正确的叶子结点实例进行配置。

6、对其他隐式双亲重复步骤4和步骤5。当且仅当隐式双亲支持的情况下，才允许为双亲结点添加双亲结点。

 

意图：控制一个对象状态转换的条件表达式过于复杂。用处理特殊状态和状态转换的State类替换条件语句。

 

动机：把状态改变的逻辑从类中去除，并搬移到表示不同状态的一系列类中，可以产生更简单的设计，它提供了观察状态间转换的更好的模型图。另一方面，如果类中的状态转换逻辑很容易理解，就不需要重构到State模式。

在重构到State模式前，考虑简单的重构能否能够帮助我们整理状态转换条件逻辑是很有好处的。如果不能，重构到State模式是可以帮助我们去除或减少许多条件逻辑，产生更易于理解和扩展的代码。

 

优点和缺点：

＋减少或去除状态改变的条件逻辑。

＋简化了复杂的状态改变逻辑。

＋提供了观察状态改变逻辑的很好的模型图。

－当状态转换逻辑已经易于理解的时候，会增加设计的复杂度。

 

做法：

1、上下文类是包含原始状态字段的类，在状态转换过程中，原始状态字段会被一系列常量赋值或与之比较。在原始状态字段上应用用类替换类型代码重构，这样它的类型就变成了一个类。我们称这个新类为状态朝类。

2、状态超类中的每个常量现在都引用着状态超类的一个实例。应用提炼子类重构，为每个常量产生一个子类，然后更新状态超类中的常量，使它们引用相应的子类实例。

3、在上下文类中找出根据状态转换逻辑来修改最少的前提下使这个新方法可以运行。

4、选择上下文类能够进入状态，然后识别出状态朝类中的哪些方法会使这个状态转换到其他状态。

5、删除每个步骤3中被复制到状态朝类的方法的方法体，为每个方法产生一个空实现。

 

动机：把每个装饰功能放在单独的类中，并让这个类包装它所要装饰的对象，因此当需要执行特殊行为时，客户代码就可以在运行时使用装饰功能包装对象。

 

优点和缺点：

＋把装饰功能从类中搬移去除，从而简化子类。

＋有效地把类地核心职责和装饰功能区分开来。

＋可以去除几个相关类中重复地装饰逻辑。

－改变了被装饰对象地对象类型。

－会使代码变得更难理解和调试。

－当Decorator组合产生负面影响的时候，会增加设计的复杂度。

 

做法：

1、确定或创建包装类型、接口或类，它声明了客户代码需要的被修饰类的公共方法。

2、找到为被修饰类添加装饰功能的条件逻辑，并应用用多态替换条件式重构去除这些逻辑。

3、步骤2产生了被修饰类的一个或多个子类。应用用委托替代继承重构把这些子类转换成委托类。

4、每个委托类都用被修饰类的新建实例对自己的委托字段进行了赋值。确保这个赋值逻辑语句在委托类的构造函数。然后提取参数重构提取赋值语句中实例化被修饰类的部分。如果可能的话，重复应用移除构造函数中不必要的参数。