??xml version="1.0" encoding="utf-8" standalone="yes"?> RUPQ?a target=_new>Rational Unified ProcessQ?a target=_new>l一软g开发过E?/font>Q?font face=Verdana color=#0000ff>l一软gq程)是一?a target=_new>面向对象且基于网l的E序开发方法论。根据Rational(Rational Rose?a target=_new>l一建模语言的开发?的说法,好像一个在U的指导者,它可以ؓ所有方面和层次的程序开发提供指导方针,模版以及事例支持?RUP?a target=_new>c?/font>似的产品--例如面向对象?a target=_new>软gq程QOOSPQ,以及OPEN Process都是理解性的软g工程工具--把开发中面向q程的方面(例如定义的阶D,技术和实践Q和其他开发的lgQ例如文,模型Q手册以及代码等{)整合在一个统一?a target=_new>框架内?/font> 一、六大经?/strong> q代式开发。在软g开?/font>的早期阶D就惛_全、准的捕获用户?a target=_new>需?/font>几乎是不可能的。实际上Q我们经帔R到的问题是需求在整个软g开发工E中l常会改变。P代式开发允许在每次q代q程中需求可能有变化Q通过不断l化来加深对问题的理解。P代式开发不仅可以降低项目的风险Q而且每个q代q程以可以执行版本结束,可以鼓舞开发h员?/font> 理需求。确定系l的需求是一个连l的q程Q开发h员在开发系l之前不可能完全详细的说明一个系l的真正需求。RUP描述了如何提取、组l系l的功能和约束条件ƈ其文化,用例和脚本的使用以被证明是捕获功能性需求的有效Ҏ?/font> Zlg?a target=_new>体系l构。组件重用成ؓ可能Q系l可以由lgl成。基于独立的、可替换的、模块化lg的体pȝ构有助于理复杂性,提高重用率。RUP描述了如何设计一个有Ҏ的、能适应变化的、易于理解的、有助于重用?a target=_new>软g体系l构?/font> 可视化徏?/font>。RUP往往?a target=_new>UML联系在一P?a target=_new>软gpȝ建立可视化模型帮助h们提供管理Y件复杂性的能力。RUP告诉我们如何可视化的对Y件系l徏模,获取有关体系l构于组件的l构和行Z息?/font> 验证软g质量。在RUP中Y件质量评C再是事后q行或单独小l进行的分离zdQ而是内徏于过E中的所有活动,q样可以及早发现软g中的~陷?/font> 控制软g变更。P代式开发中如果没有严格的控制和协调Q整个Y件开发过E很快就陷入混ؕ之中QRUP描述了如何控制、跟t、监控、修改以保成功的P代开发。RUP通过软g开发过E中的制品,隔离来自其他工作I间的变_以此为每个开发h员徏立安全的工作I间?/font> 二、统一软g开发过ERUP的二l开发模?/strong> RUP软g开发生命周期是一个二l的软g开发模?/font>。横轴通过旉l织Q是q程展开的生命周期特征,体现开发过E的动态结构,用来描述它的术语主要包括周期(Cycle)、阶D?Phase)、P?Iteration)和里E碑(Milestone)Q纵轴以内容来组lؓ自然的逻辑zdQ体现开发过E的静态结构,用来描述它的术语主要包括zd(Activity)、?Artifact)、工作?Worker)?a target=_new>工作?/font>(Workflow)。如?Q? RUP中定义了一些核心概念,如下图: 四、统一软g开发过ERUP裁剪 RUP是一个通用的过E模板,包含了很多开发指南、制品、开发过E所涉及到的角色说明Q由于它非常庞大所以对具体的开发机构和目Q用RUP时还要做裁剪Q也是要对RUPq行配置。RUP像一个元q程Q通过对RUPq行裁剪可以得到很多不同的开发过E,q些软g开发过E可以看作RUP的具体实例。RUP裁剪可以分ؓ以下几步Q?/p>
1) 定本项目需要哪些工作流。RUP?个核心工作流q不L需要的Q可以取舍?/p>
2) 定每个工作需要哪些制品?/p>
3) 定4个阶D之间如何演q。确定阶D间演进要以风险控制为原则,军_每个阶段要那些工作流Q每个工作流执行C么程度,制品有那些,每个制品完成C么程度?/p>
4) 定每个阶段内的q代计划。规划RUP?个阶D中每次q代开发的内容?/p>
5) 规划工作内部结构。工作流涉及角色、活动及制品Q他的复杂程度与目规模卌色多有兟뀂最后规划工作流的内部结构,通常?a target=_new>zd?/font>的Ş式给出?/p>
五、开发过E中的各个阶D和里程?/strong> RUP中的软g生命周期在时间上被分解ؓ四个序的阶D,分别是:初始阶段(Inception)、细化阶D?Elaboration)、构造阶D?Construction)和交付阶D?Transition)。每个阶D늻束于一个主要的里程?Major Milestones)Q每个阶D|质上是两个里E碑之间的时间跨度。在每个阶段的结执行一ơ评C定q个阶段的目标是否已l满뀂如果评估结果o人满意的话,可以允许目q入下一个阶Dc? 1Q?初始阶段 初始阶段的目标是为系l徏立商业案例ƈ定目的边界。ؓ了达到该目的必须识别所有与pȝ交互的外部实体,在较高层ơ上定义交互的特性。本阶段h非常重要的意义,在这个阶D中所x的是整个目q行中的业务和需求方面的主要风险。对于徏立在原有pȝ基础上的开发项目来Ԍ初始阶段可能很短?初始阶段l束时是W一个重要的里程:生命周期目标(Lifecycle Objective)里程。生命周期目标里E碑评h目基本的生存能力?/p>
2Q?l化阶段 l化阶段的目标是分析问题领域Q徏立健全的体系l构基础Q编刉目计划,淘汰目中最高风险的元素。ؓ了达到该目的Q必d理解整个pȝ的基上,对体pȝ构作出决{,包括其范围、主要功能和诸如性能{非功能需求。同时ؓ目建立支持环境Q包括创建开发案例,创徏模板、准则ƈ准备工具?l化阶段l束时第二个重要的里E碑Q生命周期结?Lifecycle Architecture)里程。生命周期结构里E碑为系l的l构建立了管理基准ƈ佉K目小l能够在构徏阶段中进行衡量。此刻,要检验详l的pȝ目标和范围、结构的选择以及主要风险的解x案?/p>
3Q?构造阶D? 在构建阶D,所有剩余的构g和应用程序功能被开发ƈ集成Z品,所有的功能被详l测试。从某种意义上说Q构建阶D|一个制造过E,光Ҏ在管理资源及控制q作以优化成本、进度和质量?构徏阶段l束时是W三个重要的里程:初始功能(Initial Operational)里程。初始功能里E碑军_了品是否可以在试环境中进行部|Ӏ此刻,要确定Y件、环境、用h否可以开始系l的q作。此时的产品版本也常被称?#8220;beta”版?/p>
4Q?交付阶段 交付阶段的重Ҏ保软gҎl用h可用的。交付阶D可以跨几ơP代,包括为发布做准备的品测试,Z用户反馈的少量的调整。在生命周期的这一点上Q用户反馈应主要集中在品调_讄、安装和可用性问题,所有主要的l构问题应该已经在项目生命周期的早期阶段解决了?在交付阶D늚l点是第四个里程:产品发布(Product Release)里程。此Ӟ要确定目标是否实玎ͼ是否应该开始另一个开发周期。在一些情况下q个里程可能与下一个周期的初始阶段的结束重合?/p>
六、统一软g开发过ERUP的核心工作流(Core Workflows) RUP中有9个核心工作流Q分?个核心过E工作流(Core Process Workflows)?个核心支持工作流(Core Supporting Workflows)。尽?个核心过E工作流可能使h惌v传统瀑布模型中的几个阶段Q但应注意P代过E中的阶D|完全不同的,q些工作在整个生命周期中一ơ又一ơ被讉K?个核心工作流在项目中轮流被用,在每一ơP代中以不同的重点和强度重复?/p>
1Q?商业建模(Business Modeling) 商业建模工作描qC如何为新的目标组l开发一个构惻Iq基于这个构惛_商业用例模型和商业对象模型中定义l织的过E,角色和责仅R? 2Q?需?Requirements) 需求工作流的目标是描述pȝ应该做什么,q开发h员和用户p一描述达成p。ؓ了达到该目标Q要寚w要的功能和约束进行提取、组l、文化Q最重要的是理解pȝ所解决问题的定义和范围?/p>
3Q?分析和设?Analysis & Design) 分析和设计工作流需求{化成未来pȝ的设计,为系l开发一个健壮的l构q调整设计其与实现环境相匹配,优化其性能。分析设计的l果是一?a target=_new>设计模型和一个可选的分析模型。设计模型是源代码的抽象Q由设计cd一些描q组成。设计类被组l成h良好接口?a target=_new>设计?/font>(Package)和设?a target=_new>子系l?/font>(Subsystem)Q而描q则体现了类的对象如何协同工作实现用例的功能?设计zd以体pȝ构设计ؓ中心Q体pȝ构由若干l构视图来表达,l构视图是整个设计的抽象和简化,该视图中省略了一些细节,佉K要的特点体现得更加清晰。体pȝ构不仅仅是良好设计模型的承蝲媒介Q而且在系l的开发中能提高被创徏模型的质量? 4Q?实现(Implementation) 实现工作的目的包括以层ơ化的子pȝ形式定义代码的组l结构;以组件的形式(?a target=_new>文g、二q制文g、可执行文g)实现cd对象Q将开发出的组件作为单元进行测试以及集成由单个开发者(或小l)所产生的结果,使其成ؓ可执行的pȝ? 5Q?试(Test) 试工作要验证对象间的交互作用Q验证Y件中所有组件的正确集成Q检验所有的需求已被正的实现, 识别q确 认缺陷在软g部v之前被提出ƈ处理。RUP提出了P代的ҎQ意味着在整个项目中q行试Q从而尽可能早地发现~陷Q从Ҏ上降低了修改~陷的成本。测试类g三维模型Q分别从可靠性、功能性和pȝ性能来进行?/p>
6Q?部v(Deployment) 部v工作的目的是成功的生成版本q将软g分发l最l用戗部|工作流描述了那些与保软g产品Ҏl用户具有可用性相关的zdQ包括:软g打包、生成Y件本w以外的产品、安装Y件、ؓ用户提供帮助。在有些情况下,q可能包括计划和q行beta试版、移植现有的软g和数据以及正式验收?/p>
7Q?配置和变更管?Configuration & Change Management) 配置和变更管理工作流描绘了如何在多个成员l成的项目中控制大量的物。配|和变更理工作提供了准则来管理演化系l中的多个变体,跟踪软g创徏q程中的版本。工作流描述了如何管理ƈ行开发、分布式开发、如何自动化创徏工程。同时也阐述了对产品修改原因、时间、h员保持审计记录?/p>
8Q?目理(Project Management) 软g目理q各种可能产生冲突的目标,理风险Q克服各U约束ƈ成功交付使用h意的产品。其目标包括Qؓ目的管理提供框Ӟ划、h员配备、执行和监控目提供实用的准则,为管理风险提供框架等?/p>
9Q?环境(Environment) 环境工作的目的是向软g开发组l提?a target=_new>软g开发环?/font>Q包括过E和工具。环境工作流集中于配|项目过E中所需要的zdQ同样也支持开发项目规范的zdQ提供了逐步的指导手册ƈ介绍了如何在l织中实现过E?/p>
七、RUP的P代开?a target=_new>模式 RUP中的每个阶段可以q一步分解ؓq代。一个P代是一个完整的开发@环,产生一个可执行的品版本,是最l品的一个子集,它增量式地发展,从一个P代过E到另一个P代过E到成ؓ最l的pȝ?传统上的目l织是顺序通过每个工作,每个工作只有一ơ,也就是我们熟悉的瀑布生命周期Q见?Q。这样做的结果是到实现末期品完成ƈ开始测试,在分析、设计和实现阶段所遗留的隐藏问题会大量出现Q项目可能要停止q开始一个O长的错误修正周期? ? RUP的P代模? 与传l的瀑布模型相比较,q代q程h以下优点Q?/p>
降低了在一个增量上的开支风险。如果开发h员重复某个P代,那么损失只是q一个开发有误的q代的花贏V?/p>
降低了品无法按照既定进度进入市场的风险。通过在开发早期就定风险Q可以尽早来解决而不至于在开发后期匆匆忙忙? 加快了整个开发工作的q度。因为开发h员清楚问题的焦点所在,他们的工作会更有效率?/p>
׃用户的需求ƈ不能在一开始就作出完全的界定,它们通常是在后箋阶段中不断细化的。因此,q代q程q种模式佉K应需求的变化会更Ҏ些? 八、统一软g开发过ERUP的十大要?/strong> 1. 开发前? 让我们逐一的审视这些要素,看一看它们什么地斚w合QԌQͼ扑և它们能够成ؓ十大要素的理由?br> 2. 达成计划 在较单的目中,对这些计划的陈述可能只有一两句话。比如,配置理计划可以单的q样陈述Q每天结束时Q项目目录的内容会被压~成ZIP包,拯C个ZIP盘中,加上日期和版本标{,攑ֈ中央档案柜中?软g开发计划的格式q远没有计划zd本n以及驱动q些zd的思想重要。正如Dwight D.Eisenhower所_“plan什么也不是Qplanning才是一切?#8221; “达成计划”—和列表中第3???条一起—抓住了RUP中项目管理流E的要点。项目管理流E包括以下活动:构思项目、评估项目规模和风险、监与控制目、计划和评估每个q代和阶Dc? 3. 标识和减风?/strong> 4. 分配和跟tQ?/strong> 5. 查商业理?/strong> 6. 设计lg构架 7. 对品进行增量式的构建和试 8. 验证和评L?/strong> 9. 理和控制变?/strong> 10. 提供用户支持 九、ȝ RUPh很多长处Q提高了团队生力,在P代的开发过E、需求管理、基于组件的体系l构、可视化软g建模、验证Y件质量及控制软g变更{方面,针对所有关键的开发活动ؓ每个开发成员提供了必要的准则、模板和工具指导Qƈ保全体成员׃n相同的知识基。它建立了简z和清晰的过E结构,为开发过E提供较大的通用性。但同时它也存在一些不I RUP只是一个开发过E,q没有涵盖Y件过E的全部内容Q例如它~少关于软gq行和支持等斚w的内容;此外Q它没有支持多项目的开发结构,q在一定程度上降低了在开发组l内大范围实现重用的可能性。可以说RUP是一个非常好的开端,但ƈ不完,在实际的应用中可以根据需要对其进行改qƈ可以用OPEN和OOSP{其他Y件过E的相关内容对RUPq行补充和完善?RUP
三、统一软g开发过ERUP核心概念
角色Q描q某个h或者一个小l的行ؓ与职责。RUP预先定义了很多角艌Ӏ?br> zdQ是一个有明确目的的独立工作单元?br> 工gQ是zd生成、创建或修改的一D信息?/p>
一U更灉|Q风险更的Ҏ是多ơ通过不同的开发工作流Q这样可以更好的理解需求,构造一个健壮的体系l构Qƈ最l交付一pd逐步完成的版本。这叫做一个P代生命周期。在工作中的每一ơ顺序的通过UCؓ一ơP代。Y件生命周期是q代的连l,通过它,软g是增量的开发。一ơP代包括了生成一个可执行版本的开发活动,q有使用q个版本所必需的其他辅助成分,如版本描q、用h等。因此一个开发P代在某种意义上是在所有工作流中的一ơ完整的l过Q这些工作流臛_包括Q需求工作流、分析和设计工作、实现工作流、测试工作流。其本n像一个小型的瀑布目Q见?Q?
2. 达成计划
3. 标识和减风?
4. 分配和跟tQ务。?
5. 查商业理?
6. 设计lg构架
7. 对品进行增量式的构建和试
8. 验证和评L?
9. 理和控制变?
10. 提供用户支持
1. 开发一个前?/strong>
有一个清晰的前景是开发一个满x众真正需求的产品的关键?前景抓住了RQP需求流E的要点Q分析问题,理解涉众需求,定义pȝQ当需求变化时理需求?前景l更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样Q它是Y仉目的一个清晰的、通常是高层的视图Q能被过E中M决策者或者实施者借用。它捕获了非帔R层的需求和设计U束Q让前景的读者能理解要开发的pȝ。它q提供了目审批程的输入,因此׃商业理由密切相关。最后,׃前景构成?#8220;目是什么?”?#8220;Z么要q行q个目Q?#8221;Q所以可以把前景作ؓ验证来决策的方式之一?对前景的陈述应该能回{以下问题,需要的话这些问题还可以分成更小、更详细的问题: ? 关键术语是什么?Q词汇表Q?? 我们试解决的问题是什么?Q问题陈qͼ ? 涉众是谁Q用h谁?他们各自的需求是什么? ? 产品的特性是什么? ? 功能性需求是什么?Q?a target=_new>Qs?Qases) ? 非功能性需求是什么? ? 设计U束是什么?
“产品的质量只会和产品的计划一样好?#8221; (2) 在RQP中,软g开发计划(QIQͼl合了管理项目所需的各U信息,也许会包括一些在先启阶段开发的单独的内宏VSDP必须在整个项目中被维护和更新?QIQ定义了目旉表(包括目计划和P代计划)和资源需求(资源和工PQ可以根据项目进度表来跟t项目进展。同时也指导了其他过E内容(原文Qprocess componentsQ的计划Q项目组l?a target=_new>需求管?/font>计划?a target=_new>配置理计划、问题解册划、QA计划、测试计划、评估计划以及品验收计划?
RUP的要点之一是在目早期标识ƈ处理最大的风险。项目组标识的每一个风险都应该有一个相应的~解或解册划。风险列表应该既作ؓ目zd的计划工P又作为确定P代的基础?
有一点在M目中都是重要的Q即q箋的分析来源于正在q行的活动和q化的品的客观数据。在RUP中,定期的项目状态评估提供了讲述、交和解决理问题、技术问题以及项目风险的机制?a target=_new>团队一旦发Cq些障碍物(qQ,他们把所有这些问题都指定一个负责hQƈ指定解决日期。进度应该定期跟t,如有必要Q更新应该被发布。(原文Qupdates should be issued as necessary。) q些目“快照”H出了需要引L理注意的问题。随着旉的变?虽然周期可能会变化(原文QWhile the period may vary。)Q定期的评估使经理能捕获目的历Ԍq且消除M限制q度的障或瓉?
商业理由从商业的角度提供了必要的信息Q以军_一个项目是否值得投资。商业理p可以帮助开发一个实现项目前景所需的经计划。它提供了进行项目的理由Qƈ建立l济U束。当目l箋Ӟ分析人员用商业理由来正确的估投资回报率(ROIQ即return on investment)?商业理由应该l项目创Z个简短但是引人注目的理由Q而不是深入研I题的l节Q以使所有项目成员容易理解和C它。在关键里程处Q经理应该回֕业理由,计算实际的花贏V预计的回报Q决定项目是否l进行?
在RUP中,件系l的构架是指一个系l关键部件的l织或结构,部g之间通过接口交互Q而部件是׃些更的部g和接口组成的。即主要的部分是什么?他们又是怎样l合在一LQ?RUP提供了一U设计、开发、验证构架的很系l的Ҏ。在分析和设计流E中包括以下步骤Q定义候选构架、精化构架、分析行为(用例分析Q、设计组件?要陈q和讨论软g构架Q你必须先创Z个构架表C方式,以便描述构架的重要方面。在RUP中,构架表示pY件构架文档捕P它给构架提供了多个视图。每个视N描述了某一l涉众所兛_的正在进行的pȝ的某个方面。涉众有最l用戗设计h员、经理、系l工E师?a target=_new>pȝ理员,{等。这个文ɾpȝ构架师和其他目l成员能׃构架相关的重大决{进行有效的交流?
在RUP中实现和试程的要Ҏ在整个项目生命周期中增量的编码、构建、测试系l组Ӟ在先启之后每个P代结束时生成可执行版本。在_阶段后期Q已l有了一个可用于评估的构架原型;如有?要,它可以包括一个用L面原型。然后,在构建阶D늚每次q代中,lg不断的被集成到可执行、经q测试的版本中,不断地向最l品进化。动态及时的配置理?a target=_new>复审zd也是q个基本q程元素Q原文:essential process elementQ的关键?
思义QRUP的P代评估捕获了q代的结果。评估决定了q代满评h标准的程度,q包括学到的教训和实施的q程改进?Ҏ目的规模和风险以及q代的特点,评估可以是对演示及其l果的一条简单的U录Q也可能是一个完整的、正式的试复审记录?q儿的关键是既关注过E问题又x产品问题。越早发现问题,p没有问题。(原文QThe sooner you fall behind, the more time you will have to catch up.Q?
RUP的配|和变更理程的要Ҏ当变化发生时理和控刉目的规模Qƈ且诏I整个生命周期。其目的是考虑所有的涉众需求,可能的满Q同时仍能及时的交付合格的品?用户拿到产品的第一个原型后Q往往在这之前׃要求变更Q,他们会要求变更。重要的是,变更的提出和理q程始终保持一致?在RUP中,变更h通常用于记录和跟t缺陷和增强功能的要求,或者对产品提出的Q何其?a target=_new>cd的变更请求。变更请求提供了相应的手D|评估一个变更的潜在影响Q同时记录就q些变更所作出的决{。他们也帮助保所有的目l成员都能理解变更的潜在影响?
在RUP中,部v程的要Ҏ包装和交付品,同时交付有助于最l用户学习、用和l护产品的Q何必要的材料?目l至要l用h供一个用h南(也许是通过联机帮助的方式提供)Q可能还有一个安装指南和版本发布说明?Ҏ产品的复杂度Q用户也许还需要相应的培训材料。最后,通过一个材料清单(BOM表,即Bill of MaterialsQ清楚地记录应该和品一起交付哪些材料?关于需?有h看了我的要素清单后,可能会非怸同意我的选择。例如,他会问,需求在哪儿呢?他们不重要吗Q我会告诉他我ؓ什么没有把它们包括q来。有Ӟ我会问一个项目组Q特别是内部目的项目组Q:“你们的需求是什么?”Q而得到的回答却是Q?#8220;我们的确没有什么需求?#8221; 刚开始我Ҏ非常惊讶Q我有军方的宇航开发背景)。他们怎么会没有需求呢Q当我进一步询问时Q我发现Q对他们来说Q需求意味着一套外部提出的强制性的陈述Q要求他们必L么P否则目验收׃能通过。但是他们的没有得到这L陈述。尤其是当项目组陷入了边研究边开发的境地Ӟ产品需求从头到N在演化?因此Q我接着问他们另外一个问题:“好的Q那么你们的产品的前景是什么呢Q?#8221;。这时他们的眼睛亮了h。然后,我们非常利的就W一个要素(“开发一个前?#8221;Q中列出的问题进行了沟通,需求也自然而然的流动着Q原文:and the requirements just flow naturally.Q?也许只有对于按照有明需求的合同工作的项目组Q在要素列表中加?#8220;满需?#8221;才是有用的。请CQ我的清单仅仅意味着q行q一步讨论的一个v炏V?
]]>
状态模式的UML囑֦下:
星际中h族的机枪兵Marine有两U状态:普通状态和打了兴奋针后的状态,两种状态下机枪늚开枪频率是不同的,我们用状态模式来实现机枪늚fire()Ҏ?br>
首先定义抽象状态State接口Q这个接口指定了机枪늚fire行ؓQ?br>
public interface State {
public void fire();
}
State接口有一个fire()ҎQ我们实C个子cNormalState和ExcitedStateQ分别表C普通状态和打了兴奋针后的状态,q实现具体的fireҎQ?br>
public class NormalState implements State {
public void fire() {
System.out.println("普通状态每U开?ơ?);
}
}
public class ExcitedState implements State {
public void fire() {
System.out.println("兴奋状态每U开?ơ?);
}
}
最后,定义机枪늱MarineQ每个Marine的实例代表一个机枪兵Q?br>
public class Marine {
// 保持一个状态类的实例:
private State state = new NormalState();
// 为机枪兵讄状态:
public void setState(State state) {
this.state = state;
}
// fire()ҎQ实际调用的是state变量的fire()ҎQ?br> public void fire() {
state.fire();
}
}
最后我们看看如何在客户端控制一个机枪兵的状态:
public static void main(String[] args) {
// 创徏一个机枪兵的实例:
Marine marine = new Marine();
// 调用fire()ҎQ?br> marine.fire();
// 讄为兴奋状态:
marine.setState(new ExcitedState());
// 再调用fire()ҎQ?br> marine.fire();
}
对同一个Marine对象调用两次fire()ҎQ屏q输ZؓQ?br>
普通状态每U开?ơ?br>兴奋状态每U开?ơ?/font>
可见机枪兵在两种状态下的同一个fire()Ҏ有不同的行ؓ?br>
使用状态模式的好处是每个状态被装C个独立的cMQ这些类可以独立变化Q而主对象中没有繁琐的swich-case语句Qƈ且添加新的状态非常容易,只需要从Statez一个新cd可?br>
]]>
今天充分理解了什么是开闭原则?
原话?#8220;Sofstware entities should be open for extension ,but closed for modification”
一个Y件实体应当是Ҏ展开放,对修改关闭?
阎宏的理解是Q在设计一个模块的时候,应当是这个模块可以在不被修改的前提下被扩展;应当可以
在不必修Ҏ代码的情况下改变q个模块的行为?
2. 开闭原则的思想
Q?Q抽象与具体在程序设计思想中的体现
我觉得就是体C一U稳定中又包含变化的思想。系l的核心l构是相对稳定的Q在设计它的时候,
p提取可变化的部分QŞ成对变化的抽象,最后万变不d中。可扩展的范围不是Q意的Q而是?
你的E_的那部分Q对变化的抽象)所允许的范围内。当过了这个范围那么稳定的也要发生改变?
Q?Q开闭原则在Java中的体现
如何控制变化Q也是阎宏所说的“抽象化是关键”?
最为精彩的那部分是׃从抽象层导出一个或多个新的具体cd以改变系l的行ؓQ因此系l的设计
Ҏ展是开攄。对于这U抽象的ҎQ在JAVA 中有Java接口和抽象类?
Q?Q对可变性的装原则
q个概念非常_ֽQ开闭原则中?#8220;?#8221;Q就是要把这些变化封闭v来。我们在做设计时要改变思维
方式Q?#8220;考虑你的设计中什么可能会发生变化。与通常焦ҎC么会D涉及改变的思考方式正
好相反,q一思\考虑的不是什么会D设计的改变,而是考虑你允总么发生变化而不让这一变化
D重新设计”?
q就要求可变性汇集和可变性独?nbsp;
在需求分析过E中,力的区抓住用户相对E_的需?分析变化的需?
q有的h认ؓ人生如何Q但是结果都是殊途同归,
但是无\l果如何Q有句广告词说的好,人生是一场旅行,在乎的不是目的地Q而是沉K的风景及看风景的心情?/p>
cdQ?/b>生活随笔 查看评论
文章来源:http://hi.baidu.com/whxleem/blog/item/2c4bc0ca94752c47f31fe71c.html
]]>
JNDI(Java Naming and Directory Interface)是一个应用程序设计的APIQ?/p> |
1、FACTORY—追MM不了请吃饭了,麦当劳的鸡翅和肯德基的鸡都是MM爱吃的东西,虽然口味有所不同Q但不管你带MM去麦当劳或肯德基Q只向服务员说“来四个鸡翅”就行了。麦当劳和肯德基是生鸡翅的Factory
工厂模式Q客L和工厂类分开。消费者Q何时候需要某U品,只需向工厂请求即可。消费者无M改就可以接纳C品。缺Ҏ当品修ҎQ工厂类也要做相应的修改。如Q如何创建及如何向客L提供?nbsp;
2、BUILDER—MM最爱听的就是“我׃”这句话了,见到不同地方
x惛_长大后的q真的是没什么意思,有的只是可以休息一?/p>
cdQ?/b>生活随笔 查看评论
文章来源:http://hi.baidu.com/whxleem/blog/item/ada816e9abdd9c3fb90e2df1.html
]]>