下载文档原格式
软件研发中的敏捷开发与迭代式开发模式在软件研发领域，敏捷开发和迭代式开发模式是两种常用的方法。
它们都旨在提高开发效率和项目成功率。
本文将探讨敏捷开发和迭代式开发模式的特点、优势及其在软件研发中的应用。
一、敏捷开发模式敏捷开发模式是一种迭代、增量开发方法，能够快速响应需求变化并灵活适应不断变化的项目环境。
敏捷开发模式注重迅速交付可用软件，并通过与客户的密切合作，及时反馈和调整开发方向。
敏捷开发模式的核心价值观包括个体和互动、工作的软件、客户合作和响应变化。
敏捷开发模式的特点如下：1. 需求灵活调整：敏捷开发模式允许在开发过程中灵活调整需求，根据实际情况进行优先级排序，并及时响应变化。
这使得软件开发能够适应项目的实际需求，提高开发效率和质量。
2. 增量交付：敏捷开发模式强调每个迭代周期内交付部分可用软件，以实现快速反馈和客户验收。
这种增量交付的方式使开发团队更容易掌握项目进展，减少风险，并使客户能够尽早使用软件。
3. 高度透明：敏捷开发模式要求开发团队与客户之间保持密切的协作和沟通，确保需求的准确理解和项目的透明度。
通过日常站会、迭代评审等方式，加强团队之间的沟通和协作，减少沟通成本和风险。
敏捷开发模式在软件研发中的应用广泛。
尤其适合需求不明确或需求变化频繁的项目。
通过敏捷开发，可以更好地应对市场竞争和技术变革，减小项目风险，提高软件质量和客户满意度。
二、迭代式开发模式迭代式开发模式是一种将软件开发过程划分为多个迭代周期进行的方法。
每个迭代周期包括需求分析、设计、开发、测试等开发阶段，并以可交付的软件版本作为迭代结果。
迭代式开发模式注重每次迭代周期内的软件开发和反馈，通过不断迭代，逐步完善和优化软件。
迭代式开发模式的特点如下：1. 渐进开发：迭代式开发模式通过多次迭代循环，逐渐完善软件功能和质量。
每个迭代周期交付一部分功能完整的软件，方便针对用户反馈进行修改和优化。
2. 有限制的规划：迭代式开发模式以一定时间范围的迭代为基本单位，每个迭代都有明确的目标和范围。
软件开发中的敏捷开发模式介绍随着信息技术的飞速发展，软件行业成为了现代经济中不可或缺的一部分。
在这一领域，软件开发是至关重要的一个环节，它直接关系到软件产品的质量、效率和用户体验。
为了更好地满足市场需求，提高软件开发的效率和质量，人们需要不断探索有效的软件开发模式。
其中最具有代表性的就是敏捷开发模式。
敏捷开发模式，就是提倡轻量级、迭代式和协作化的软件开发方式。
相比传统的瀑布模型，它更加灵活和适应变化，能够快速响应市场需求，加快软件产品上市时间。
下面分别从敏捷开发思想、敏捷开发原则和敏捷开发实践等方面对其进行介绍。
一、敏捷开发思想敏捷开发模式是由17位软件开发者在2001年2月聚集在犹他州的一间旅馆讨论的产物。
他们致力于改变当时软件开发业中的陈旧思维和严格流程，提出了敏捷开发的概念。
敏捷开发思想最主要的特征就是反对一切不必要的文档、不必要的工作、不必要的环节和不必要的过程，强调迅速响应变化、人性化合作和持续改进。
通过不断实践和反思，不断发掘和削弱软件开发中的痛点和障碍，让敏捷开发理念更加贴合现实。
二、敏捷开发原则敏捷开发模式的核心是敏捷开发原则，也就是在实践过程中必须要遵守的一些基本规则。
以下是敏捷开发的12条原则：1. 个人和互动高于流程和工具2. 可以工作的软件高于详尽的文档3. 客户合作高于合同谈判4. 响应变化高于遵循计划5. 每个人都提供价值6. 保持稳定的步调7. 强调自我组织的团队8. 鼓励面对面的交流9. 度量进展的主要标准是运行的软件10. 不断的技术升级和提高设计的熟练程度11. 持续关注卓越的水平12. 简单即美这些原则旨在通过大胆尝试和反馈机制，不断寻找适合的方案，激励团队的创造性和思考能力，不断提高软件开发效率和质量。
三、敏捷开发实践敏捷开发原则的实践是不可避免的过程。
下面我们结合敏捷开发原则，从团队、需求、设计和测试等方面，介绍敏捷开发的实践方法：1. 团队管理敏捷开发模式下，对于团队的管理非常重要。
软件开发的敏捷方法
敏捷开发是一种以人为核心、迭代、逐步增量的软件开发方法。
与传统的瀑布式开发方法不同，敏捷开发注重团队合作、快速反馈和适应变化。
敏捷开发方法的主要特点包括：
1. 迭代开发：将整个开发过程分为多个短期迭代，每个迭代都会交付可用的软件产品。
这样可以快速获得用户反馈，并根据反馈进行调整。
2. 增量开发：软件功能会逐渐增加，每个迭代都会增加新功能或改善现有功能。
这可以提高软件的可理解性和用户满意度。
3. 自我组织团队：敏捷开发强调团队成员之间的合作和互相信任。
团队成员可以根据需要自行分配工作和解决问题。
4. 快速反馈：通过尽早且经常地向用户展示软件产品，可以更好地理解用户需求并修正问题。
这样可以避免在开发结束时才发现问题。
5. 适应变化：敏捷开发方法可以根据市场需求和用户反馈进行快速调整。
通过频繁的迭代，可以更容易地适应变化和创新。
目前，常见的敏捷开发方法有Scrum、极限编程(XP)、Kanban 等。
这些方法都强调团队合作、自组织、快速交付和快速迭代的特点，以适应不断变化的市场需求和用户需求。
软件工程实践指南：敏捷开发与版本控制导言：软件工程实践是指通过系统化的方法和原则来设计、开发、测试和维护软件的过程。
在软件工程实践中，敏捷开发和版本控制是两个重要的方面。
本文将详细介绍敏捷开发和版本控制的定义、步骤和实践方法。
一、敏捷开发1. 定义：敏捷开发，又称为敏捷软件开发，是一种迭代和增量的开发方法，强调团队合作、快速适应变化和持续交付的原则。
2. 步骤：a. 客户需求收集：与客户密切合作，深入了解客户的需求和期望。
b. 产品backlog管理：将客户需求转化为产品backlog，按优先级排序。
c. 迭代计划：将产品backlog分解为可执行的迭代计划。
d. 迭代开发：按照迭代计划进行软件开发，每个迭代通常持续1-4周。
e. 迭代回顾：每个迭代结束后进行回顾和总结，改进下一次迭代计划。
f. 持续交付：根据业务需求，及时交付可用、可测试的产品版本。
3. 实践方法：a. Scrum：是一种常用的敏捷开发方法，以产品backlog、迭代计划和迭代回顾为核心。
b. Kanban：通过可视化的方式管理任务流程，实现任务优先级和进度的可视化控制。
c. 用户故事：以用户角色、目标和愿望为基础，将需求表达为简洁的故事型描述。
d. 自动化测试：通过自动测试工具和框架，提高测试效率和软件质量。
二、版本控制1. 定义：版本控制，又称为代码管理或源代码控制，是一种管理和跟踪软件开发过程中代码版本的方法。
2. 步骤：a. 创建代码仓库：使用版本控制工具创建代码仓库，保存和管理代码的历史版本。
b. 分支管理：根据开发需要，创建主分支和功能分支，分别用于稳定版本和新功能开发。
c. 提交和合并：开发人员通过提交代码来记录代码变更，并通过合并操作将多个分支的代码合并到主分支。
d. 冲突解决：当多个开发人员同时修改同一文件时，可能会产生冲突，需要手动解决冲突。
e. 版本发布：当达到一个稳定的阶段时，可以将代码发布为一个新的版本，用于部署和交付。
软件开发中的敏捷开发模式敏捷开发模式是软件开发领域中常用的一种开发方法，其以快速反馈、灵活性和适应性为核心原则。
在软件开发的初期，传统的瀑布模型经常面临诸多挑战，敏捷开发模式因其高效性和适应性而逐渐受到广大开发者的青睐。
本文将深入探讨软件开发中的敏捷开发模式，包括其定义、特点以及优势。
一、敏捷开发模式的定义敏捷开发模式，顾名思义，强调在软件开发过程中的快速、灵活和适应性。
该方法的核心理念是以人和互动为中心，注重软件开发过程中不断改进和反馈。
与传统的瀑布模型相比，敏捷开发模式更加注重开发人员与客户之间的合作和交流。
二、敏捷开发模式的特点1.迭代开发：敏捷开发模式将软件开发过程划分为若干个迭代周期，每个迭代周期都会产生可用且具备较高价值的软件产品。
2.增量交付：敏捷开发模式通过持续的迭代开发，每个迭代周期都会交付一部分完整的软件功能，不仅减少了项目失败风险，还增加了客户对软件产品的信任和满意度。
3.强调团队合作：敏捷开发模式鼓励开发团队内部成员之间的密切合作和交流，通过团队的协作，提高软件开发效率和质量。
4.注重实效性：敏捷开发模式追求实际的效果，更加关注软件产品的实际业务需求，及时调整开发计划和需求变更。
三、敏捷开发模式的优势1.快速反馈：敏捷开发模式能够较快地为开发人员提供客户的反馈意见，通过及时的沟通和调整，可以减少项目开发过程中的错误和偏差。
2.灵活适应：敏捷开发模式能够灵活适应需求的变化，开发团队可以及时根据客户反馈和市场变化进行调整，降低了项目风险。
3.高质量交付：敏捷开发模式通过持续的迭代和自动化测试，能够在每个迭代周期交付高质量的软件产品，满足客户的需求。
4.客户满意度：敏捷开发模式注重与客户的紧密合作和交流，可以更好地理解客户需求，提高客户的满意度和信任度。
总结：敏捷开发模式作为一种高效、灵活和适应性强的软件开发方法，为软件行业带来了许多好处。
其迭代开发、增量交付、团队合作和实效性的特点，使得软件开发过程更加高效和贴近客户需求。
软件工程---敏捷软件开发软件工程敏捷软件开发在当今快速发展的科技世界中，软件开发的方法和理念也在不断演进。
其中，敏捷软件开发作为一种备受关注和广泛应用的方法，为软件开发带来了全新的思路和高效的实践。
那么，什么是敏捷软件开发呢？简单来说，它是一种应对快速变化的需求和环境的软件开发方法。
与传统的软件开发方法相比，敏捷更注重灵活性、协作以及快速响应变化。
敏捷软件开发的核心原则包括客户合作、拥抱变化、频繁交付、团队自组织等等。
客户合作意味着开发团队要与客户保持紧密的沟通，深入了解他们的需求和期望。
在传统开发中，客户往往在项目的最后阶段才看到成果，而在敏捷中，客户能够在整个开发过程中参与并提供反馈。
拥抱变化这一原则更是敏捷的精髓所在。
在软件开发过程中，需求的变更几乎是不可避免的。
敏捷方法认为变化是正常的，而不是一种麻烦。
通过短周期的迭代开发，团队能够及时调整方向，确保最终的产品能够真正满足客户的需求。
频繁交付也是敏捷的重要特点。
相比于传统方法中长时间的开发周期后才交付一个完整的产品，敏捷提倡在较短的时间内交付可工作的软件增量。
这样可以让客户更早地看到成果，同时也有助于及时发现问题和改进。
团队自组织则强调团队成员能够自主地做出决策，共同解决问题，而不是依赖于严格的层级管理。
这样可以充分发挥每个成员的创造力和积极性，提高团队的效率和生产力。
敏捷软件开发通常采用一些特定的方法和实践，比如 Scrum 和Kanban 。
Scrum 是一种基于迭代和增量的框架，它将开发过程分为一系列短的迭代周期，称为“冲刺” 。
在每个冲刺开始时，团队确定要完成的任务，然后在冲刺结束时交付可工作的产品增量。
Kanban 则是一种可视化的工作流程管理方法，通过看板来展示工作的进展和状态，帮助团队更好地管理工作流程和优化工作效率。
在实际的软件开发项目中，采用敏捷方法能够带来诸多好处。
首先，它能够显著提高项目的成功率。
由于能够及时响应变化和满足客户需求，最终交付的产品更符合预期，减少了项目失败的风险。
软件开发中的敏捷开发模式介绍随着信息技术和互联网应用的不断发展，软件开发不仅是一项重要的技术，也是一种必不可少的商业活动。
然而，软件开发周期长、成本高、需求变化频繁等问题也不断影响着软件开发的效率和质量。
敏捷开发模式就是一种应对这些问题的方法。
本文将介绍敏捷开发模式的原理、特点及优缺点。
敏捷开发的原理敏捷开发模式最初是以极限编程（Extreme Programming，XP）为代表，后来又衍生了许多其他的敏捷开发方法，如Scrum、Crystal、DSDM等。
敏捷开发的原理是通过团队协作，快速响应需求变化，保证软件开发的质量和效率。
与传统的瀑布模型相比，敏捷开发更关注软件开发的过程，强调迭代、轻量化、快速响应和灵活性。
敏捷开发的特点敏捷开发与传统的瀑布模型相比，具有如下特点：1.周期短、迭代多敏捷开发的周期一般比传统的瀑布模型更短，通常每个迭代周期为2-4周。
这样可以快速响应需求变化，同时也便于版本管理和迭代优化。
2.需求变化频繁软件开发中常常面临需求变化的情况，敏捷开发模式更加灵活，能够快速响应变化。
同时通过每个迭代周期的发布和反馈，及时了解用户需求变化和反馈，从而保证软件能够满足用户需求。
3.重视团队协作敏捷开发的成功离不开团队协作，团队成员之间的沟通和合作至关重要。
敏捷开发中一般采用面对面交流的方式，鼓励团队成员互相反馈和学习。
4.追求用户价值敏捷开发的目标是实现用户需求和期望的价值，通过频繁的发布和反馈，及时了解用户的反馈，从而不断提高软件的用户价值。
敏捷开发的优缺点敏捷开发具有如下优点：1.能够快速响应需求变化。
2.强调软件的可维护性和可扩展性。
3.注重用户价值，能够更好地满足用户需求。
4.强调团队协作，能够提高团队成员的合作意识和技能。
5.实时追踪开发进度和质量，能够及时发现和解决问题。
但是敏捷开发也存在一些缺点：1.对团队成员的素质和技能要求较高。
2.需要投入较多的人力和时间资源。
敏捷软件开发方法敏捷软件开发是一种快速、灵活和协作的软件开发方法。
与传统的瀑布模型相比，敏捷方法更注重团队协作、持续交付和客户参与。
一、敏捷软件开发的基本原则敏捷软件开发的基本原则是通过持续交付、快速反馈和灵活调整来满足不断变化的需求。
1. 个体和相互作用高于流程和工具：敏捷团队注重人与人之间的合作和沟通，而非过度依赖工具和流程。
2. 可以工作的软件高于详尽的文档：敏捷开发强调以实际可工作的软件来验证和确认需求，而非过多地侧重于繁文缛节的文档。
3. 客户合作高于合同谈判：敏捷开发鼓励开发团队与客户密切合作，通过持续的反馈与迭代，满足客户需求。
4. 响应变化高于遵循计划：敏捷开发能够快速响应需求的变化，并及时对软件进行调整和优化。
二、敏捷软件开发的核心流程敏捷软件开发通常采用迭代和增量的方式进行，最典型的方法是Scrum和Kanban。
1. Scrum方法：Scrum由一组团队成员组成，包括Scrum Master（负责协调团队工作的主管）和Product Owner（代表客户和用户的利益）。
Scrum通过一系列短期的迭代周期（称为Sprint）来实现软件的交付。
每个Sprint通常持续2到4周，团队在每个Sprint中完成一系列功能点的开发，并在Sprint结束时与客户进行演示和反馈。
2. Kanban方法：Kanban方法通过减少和控制工作流程中的工作量，使团队能够更好地处理任务。
Kanban采用可视化的方式，使用看板来跟踪任务的状态和进度。
团队根据工作量的变化和优先级，自行决定任务的安排和执行顺序。
三、敏捷软件开发的好处敏捷软件开发方法具有以下好处：1. 提高交付速度：敏捷开发以迭代和增量的方式进行，能够更快地交付符合客户需求的软件。
2. 提高客户满意度：敏捷开发鼓励与客户紧密合作，通过持续的反馈和演示，确保软件与客户期望一致。
3. 加强团队合作：敏捷开发强调团队合作和沟通，能够增强团队成员之间的协作能力和工作效率。
敏捷是一个术语，用于描述软件开发的方法，强调增量交付，团队协作，持续计划和持续学习，而不是试图在接近结束时立即交付。
敏捷专注于保持流程的精益，并创建最小的可行产品（MVP），在最终结果出现之前经历多次迭代。
不断收集和实施反馈，总而言之，这是一个更加动态的过程，每个人都在朝着一个目标努力。
Scrum和其他的敏捷方法敏捷是一种思维方式，它是一套价值观和原则。
敏捷是一种思考和行动的方式。
敏捷就是短周期，迭代和增量交付，快速失败，获得反馈，及早向客户提供商业价值，关于人员，协作和互动。
敏捷是一种关于透明度，检查和适应的心态。
但是，敏捷不包含任何角色，事件或工件。
这是一种心态。
例如，Scrum是敏捷伞下广泛使用的框架之一，它可以帮助你变得更敏捷，但敏捷运动中有更多的框架，如看板，XP，Crystal等等，如图所示下面：ScrumScrum是一个框架，人们可以在其中解决复杂的自适应问题，同时有效且创造性地提供具有较高价值的产品。
它用于管理软件项目和产品或应用程序开发。
它的重点是适应性产品开发战略，其中跨职能团队作为一个单元在2-4周内达成共同目标（Sprint）。
它由一系列价值，文物，角色，仪式，规则和较佳实践组成。
Lean (精益)精益起源于丰田生产系统（TPS），它在20世纪50年代，60年代及以后改变了实物商品的生产。
精益保持其在制造业中的地位，但也在知识工作中找到了新的应用，帮助所有行业的企业消除浪费，改进流程并促进创新。
软件开发是精益方法的自然应用，因为与制造业一样，它通常遵循一个确定的过程，具有一定的接受条件，并导致有形价值的传递。
指导精益方法所有实践的关键概念，我们称之为精益支柱。
他们是：·连续的提高·尊重人·轻量级领导看板(Kanban)看板是一种高度可视化的工作流管理方法，在精益团队中很受欢迎。
事实上，83％的精益生产团队使用看板来可视化并积极管理产品的创建，重点是持续交付，同时不会使开发团队负担过重。
敏捷软件开发:SRP单一职责原则(2009-03-24 20:30:24)转载标签：it这条原则实际就是体现内聚性原则的体现，一个模块的组成元素之间的功能相关性。
把内聚性概念扩展一下：把内聚性和引起一个模块或者类改变的作用力联系起来。
一个类应该只有一个发生变化的原因。
若Game类有2个不同的职责，一个是记录当前轮，另一个式计算分数，最后要把这两个职责分离到两个类中。
为何把这两个职责分在单独的类中呢？因为每个职责都是变化的一个轴线，当需求变化会反映为类的职责的变化。
如果一个类承担了多于一个职责，那么引起它变化的原因就会有多个。
如果一个类承担的职责太多，就等于把这些职责耦合在一起了。
一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合或导致脆弱的设计，当变化发生时，设计会遭受到预想不到的破坏。
定义职责：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，有时候我们很难注意到这点，我们习惯以组的形式去考虑职责。
public interface Modem{public void Dial(String pno);public void Handup();public void Send(char c);public char Recv();}接口包括了2个职责，第一个职责是连接管理，第二个职责是数据通信。
如果应用程序的变化方式总是导致这两个职责同时变化，那么就不要分离他们，分开他们就会有不必要的复杂性味道。
仅当变化发生时，变化的轴线才有实际意义，如果没有征兆，那么应用SRP或者任何其他原则都是比明智的。
分离耦合的职责：经常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿意耦合在一起的东西欧和在一起了。
然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦概念。
如果ModenImplementation implemet DataChannel,Conection。
ModenImplementation看起来是一个混杂物，或者有缺陷的类，所有的依赖关系都是从它发出来的。
谁都不需要依赖它，谁都不需要知道它的存在。
因此，我们已经把丑陋的部分隐藏起来了。
其丑陋性不会泄露出来，污染应用程序的其它部分。
持久化：如Emplyee:CalculatePay,Store,Emplyee类包括了业务规则和对于持久化的控制，这两个职责在大多数情况下绝不应该混合在一起。
业务规则往往会频繁地变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也不一样。
把持久化系统和业务规则绑定在一起是自讨苦吃的做法。
如果发现这种情况存在了，应该使用FACADE、dao或者proxy模式对设计进行重构，分离这两个原则。
SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。
敏捷软件开发——开放封闭原则OCP首先，让我们分析一下背景。
什么是软件开发过程中最不稳定的因素？——答案是需求！需求在软件开发过程中时时刻刻都可能发生变化。
那么，如何灵活应对变化是软件结构设计中最重要也是最困难的一个问题。
好的设计带来了极大了灵活性，不好的设计则充斥着僵化的臭味。
这样，也就引出了本文的主题：【开发封闭原则】。
下面，就来简单扼要的介绍一下什么是【开放封闭原则】。
【开发封闭原则】包括两个特征：对于扩展是开放的；对于修改是封闭的。
对于扩展开放，意味着模块的行为是可扩展的。
对于修改封闭，就是说在扩展模块行为的同时不对任何既有代码或二进制代码（.jar）进行修改。
当然，这里说的过于绝对。
有时为了完成某些任务不得不改动既有代码。
但是，我们的目标是尽量的遵守原则。
那如何才能做到对扩展开发，对修改封闭呢？关键在于抽象！那什么是抽象呢？我个人的理解是：抽象是对事物本质的概念上的理解。
面向对象的分析中应该以行为分析为主线。
举一个例子说明：假如从北京到上海，我们可以坐飞机，可以坐火车，可以坐汽车，也可以骑自行车。
那对于这个问题如何分析呢？这个问题的抽象又是什么呢？也许可以这样思考：飞机、火车、汽车和自行车在本质上都是交通工具。
所以得到这样的分析结果：交通工具被抽象为父类，飞机、火车、汽车和自行车都是其特例化的实现，父类中定义一个抽象方法，可以将人从一个地方运送到另外一个地方，各个子类重新定义运送的方式。
这个设计无可厚非！但是，注意了！如果哪天某个人心情不错，想从北京走到上海了。
那他的交通工具又是什么呢？11路！如果把步行也算成交通工具那就太不符合实际了。
所以，面向对象的分析角度，不应该是从事物物理方面的关联去分析，而应该是从事物的行为方面的管理区分析。
对于这个问题，一个人从北京道上海，无论是怎么到达的，只不过是移动策略不同。
下面，就给出相应的示例代码来说明一下上述问题。
class Traveller {private Car car = new Car();public void travel(Address srcAddress,Address destAddress){car.move(srcAddress,destAddress);}}这是最开始直接使用Car的旅行者，如果想替换成AirPlane怎么办？修改代码，用new AirPlane()代替Car。
面向对象的实践原则指出：面向接口编程，而不面向实现编程。
当代码依赖于具体实现时，就缺失了灵活性，面对新的扩展（也就是新的实现），必须修改既有代码。
接着，给出设计灵活的代码：class Traveller {private TravelStrategy _strategy;public void travel(Address srcAddress,Address destAddress){_strategy.move(srcAddress,destAddress);}public void setTravelStrategy(TravelStrategy strategy){_strategy = strategy;}}public interface TravelStrategy{void move(Address srcAddress,Address destAddress);}public class CarStrategy implements TravelStrategy{public void move(Address srcAddress,Address destAddress){...}}public class AirPlaneStrategy implements TravelStrategy{public void move(Address srcAddress,Address destAddress){...}}public class WorkStrategy implements TravelStrategy{public void move(Address srcAddress,Address destAddress){...}}使用这种设计就能灵活的应对设计。
比如说：现在需要另外一种从北京到上海的方式——爬。
呵呵，也许这种行为不可思议，但它也能达到目的。
那如何扩展呢？只需要扩展一个新的TravelStrategy实现即可。
这样，Traveller类不需要修改任何代码！可以通过调用setter方法来切换移动策略。
现在还有一个问题：如何确定实例化哪个策略？这里可以引用工厂，专门负责对象实例化。
可以将需要使用的策略放在文件中，这样改变策略时就不需要修改源代码了。
但当新增策略时，还是需要修改Factory。
没办法，现实中没有完全符合原则的情况，我们只能尽力去遵守！现在，我们看一下以上代码中类之间的关系。
Traveller类、TravelStrategy接口及其实现类，Traveller类是TravelStrategy接口的客户代码。
那Traveller和TravelStrategy的关系与TravelStrategy和它的实现类指尖的关系哪个更紧密一些呢？答案是前者。
这也正是另外一个敏捷原则【依赖倒置原则】。
高层代码不应该依赖低层代码，低层代码要依赖于高层代码。
在这里，说白了的意思就是：一个旅行者要从北京到上海，而旅行团已经给他安排好了去的方法，他本身并不关心怎么到达，只需要知道有办法到达就可以了。
这里旅行者和到达方法之间的关系就非常密切了，而具体如何到达那是低层次的问题了。
上述的问题与实现是实现【开放封闭原则】的一种常用方法——策略模式。
还有一种常用的实现方法：模板方法。
其实，对于这两种方法的本质所在也就是面向对象中的组合与继承。
我们已经学会了如何封装变化，那合适才封装呢？掌握了这项技能是一件好事，但滥用就出问题了~！因为遵循OCP的代价是昂贵的，创建正确的抽象是要花费时间和精力的，同时那些抽象也增加了软件设计的复杂性。
通常，我们采用这种办法：只受愚弄一次。
也就是说，最初的实现不封装任何东西。
当真正的变化到来了，重构代码，封装变化，以避免同类问题再次发生。
OCP是面向对象设计的核心所在。
开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。
拒绝不成熟的抽象与抽象本身一样重要。
最后，在简单介绍一下面向对象分析的常用方法：寻找问题域中的各个事物或行为共性从共性中创建抽象从共性的变化中创建派生看共性之间的关系如何敏捷软件开发读书笔记（4）——OO五大原则（3.LSP——里氏替换原则）(转)2007-05-31 09:12:06| 分类：J2EE学习 | 标签：无|字号订阅OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。
“抽象”是语言提供的功能。
“多态”由继承语义实现。
如此，问题产生了：“我们如何去度量继承关系的质量？”Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。
”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。
该原则称为Liskov Substitution Principle——里氏替换原则。
林先生在上课时风趣地称之为“老鼠的儿子会打洞”。
^_^我们来研究一下LSP的实质。
学习OO的时候，我们知道，一个对象是一组状态和一系列行为的组合体。
状态是对象的内在特性，行为是对象的外在特性。
