??xml version="1.0" encoding="utf-8" standalone="yes"?>国产一区二区久久久久,欧美日韩在线网站,99高清视频有精品视频http://www.aygfsteel.com/ghawk/category/5963.htmlzh-cnTue, 27 Feb 2007 12:08:02 GMTTue, 27 Feb 2007 12:08:02 GMT60一个XPer提供的一些经?/title><link>http://www.aygfsteel.com/ghawk/archive/2006/08/24/65536.html</link><dc:creator>GHawk</dc:creator><author>GHawk</author><pubDate>Thu, 24 Aug 2006 07:45:00 GMT</pubDate><guid>http://www.aygfsteel.com/ghawk/archive/2006/08/24/65536.html</guid><wfw:comment>http://www.aygfsteel.com/ghawk/comments/65536.html</wfw:comment><comments>http://www.aygfsteel.com/ghawk/archive/2006/08/24/65536.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.aygfsteel.com/ghawk/comments/commentRss/65536.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/ghawk/services/trackbacks/65536.html</trackback:ping><description><![CDATA[ <p>前些天,和一位XPerq行?jin)一ơ愉快的谈话。他向我讲述?jin)一些感觉很有效的实c(din)?/p> <div align="left">关于q程和P?br />他曾l参与过的项目的q代是以月ؓ(f)q代单位的,但事实上每周都会(x)重复一个简单的q程?br />在P代过E中Q他非常推崇<b><font color="#a52a2a">Burn-Down Charts</font></b>。这是一个Scrum的工兗通过Burn-Down ChartsQ能够把q程中间的变化记录下来,使过E高度可视化。等CơP代完成,回顾一下所有的Burn-Down Chartsp作ؓ(f)改进的判断依据?br /><b><font color="#a52a2a">KPT Meeting</font></b>。所谓KPT Meeting是 Keep-Prevent-Try metting。小l定期D行KPT?x)议Q基本上是每周一ơ)(j)。在KTP?x)议上,通过头脑风暴的方式每个hQ?font color="#ff0000"><b>不是某几个h</b></font>Q把各自认ؓ(f)前一阶段里做得好的方面写在Keep一栏里Q做得不好的斚w写在Prevent一栏里Q希望尝试的写在Try一栏里。然后大家对q些目q行评估和筛选。下一阶段中,Keep的项目l保持,Prevent的项目应该杜l,Try的项目进行尝试?br /><br />工具<br />在开展这些实늚时候,交流比较频繁。首推的工具?font color="#a52a2a"><b>Mini white board</b></font>?font color="#a52a2a"><b>DC</b></font>?br />选择Mini white board的原因ƈ不是因ؓ(f)带有"mini"听上M(x)?Mini Cooper 或?iPod mini 那么cool。因Z块A3左右大小的白杉K帔R合个h或者结对用,而且环保Q省M(jin)草稿U)(j)。虽然整个团队也有用于大规模交流的更大的白板Q但那属于“竞争资源”,各自使用自己的白板更为方ѝ?br />交流l果产生后,Z(jin)不花不必要的旉d_的文档,一台轻便的DC往往是最合适的选择。当?dng)如果_Q手Z的照相功能也可以完成同样的Q务。相比偷拍街上的MMQ这些电(sh)子品能够实现更大的价倹{?br /><br />关于l对<br />每天q行6时的结对编E,?ơ,每次2时。每ơ和不同的成员组队。在l队的时候充分利用了(jin)上面提到的工兯行交。如果出C个h不能解决的问题的时候,?x)立卛_整个团队提出Q这样可能导致一ơstand-up meeting。即佉K题(sh)能马上解冻I臛_也能保每个人都知道q个问题?br /><br /></div> <img src ="http://www.aygfsteel.com/ghawk/aggbug/65536.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/ghawk/" target="_blank">GHawk</a> 2006-08-24 15:45 <a href="http://www.aygfsteel.com/ghawk/archive/2006/08/24/65536.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>UP & XP之争Q意义何在?(l?http://www.aygfsteel.com/ghawk/archive/2006/04/25/43027.htmlGHawkGHawkTue, 25 Apr 2006 07:03:00 GMThttp://www.aygfsteel.com/ghawk/archive/2006/04/25/43027.htmlhttp://www.aygfsteel.com/ghawk/comments/43027.htmlhttp://www.aygfsteel.com/ghawk/archive/2006/04/25/43027.html#Feedback4http://www.aygfsteel.com/ghawk/comments/commentRss/43027.htmlhttp://www.aygfsteel.com/ghawk/services/trackbacks/43027.html虽然我没能去参加BEA的活动,但是相关的资料已l下载ƈ且浏览过?jin),实收获不少。所以,对于庄兄的这些想法我很理解?/p>

怿不只你我Q大部分的h都比较认同敏捷化的过E,希望使过E变得敏捗的,q是个好东西Q之前我也说q“敏捯E是三赢的”这L(fng)话?/p>

我所兛_(j)的问题是“如何能够用好XPQ”?/p>

庄兄认ؓ(f)“汤的味道,不需要什么过E控制”,我也?x)认同。ؓ(f)什么?因ؓ(f)你我都是中国人。大部分中国Z?x)认为汤的味道需要什么过E控制。但是想想看Q如果你在不同地方买到的肯d基炸鸡味道各异;同一Ҏ(gu)生的同型号的汽车Ş状各异;银行里取出来的一叠百元大钞大不一Q你不会(x)觉得奇怪么或是有那么一点点愤怒么Q?/p>

西方人(甚至学习(fn)西方的日本hQ对品质的重视程度却完全不同。他们不允许肯d基炸鸡的味道有很大偏差(即便你觉得无所谓)(j)Q?毫米工程”不允许整R的总装长度发生2毫米以上的偏差(即便你觉得无所谓)(j)Q百元大钞……(我想谁都不会(x)无所谓)(j)?/p>

所以,一切质量都有标准,一切标准都应该被度量!q就是工E学的目标之一Qؓ(f)?jin)实现更严格的质量标准,需要过E控制和度量?/strong>

庄兄所_(d)用测试用例保证代码的质量其实q是采用?jin)“测试用例”作为度量的标准。唯一的问题是Q“如何确保测试用例的质量”。显?dng)我们不能把一把不直的子度量出来的结果作为可靠的参考依据。怎么解决呢?“结对编E”么Q嗯Q这是一个不错的方式Q那么最l该信赖谁呢Q是Pair中的Aq是B呢?或者,是Leader么?那么又是谁提出的要求呢?是老板么?q是客户Q政府?法规Q市(jng)场?……问题没有终l了(jin)?/p>

不要学习(fn)哲学家的Ҏ(gu)Q提Z层又一层无法解决的问题。我们是工程师,应该试图解决问题才对Q解决问题的关键在于Q?font color="#ff0000">XP同样需要标准!Z(jin)制定标准Q必要的文档是不可以的。而且Q标准本w的质量是严苛的。因为,作ؓ(f)标准Q他不可以含p其辞、模׃可。在标准的基之上Q我们才可以谈什么TDD、Pair Programming之类的实c(din)?/p>

回到争论的开端。我引用?jin)林先生的话“UP是正PXP是草书。要先学好UP才能学好XPQ先学XP?x)ؕ套。”我对这句话的理解如下:(x)q句话ƈ没有批判UP或是XPQ只是指Z(jin)一个学?fn)的序。我认ؓ(f)q句话是有实践依据的Q因为UP的是一U经典的工程Ҏ(gu)。Y件工E本来就源于其他行业的工E实늻验。UP利用大量的文档对开发活动进行约束和记录。正是这U重量的过E规范了(jin)规范?jin)从PM到Coder的所有活动,有问题可以参照文档,看看自己应该怎么做。文档也可以作ؓ(f)日后评估q个q程的依据。随着整个团队和每个个人的l验不断U篏Q开发活动中的日常行为渐渐Ş成了(jin)一U职业习(fn)惯。然后可以通过对UP的配|,逐渐减少文档的用量Q一些没有必要的文档可以省去,更具团队的实际能力调整过E?font color="#ff0000">UP是可配置的,不必要的文档没有存在的理由,q一点UP和XP没有什么两栗?/strong>当然Q随着大家的职业习(fn)惯越来越好,l验来丰富,个h和团队就可以采用更敏hM的过E,逐渐q渡到XP上去?/p>

反过来,如果一开始就没有详尽的文档,很多zdQ比如设计、版本控Ӟ(j)往往?x)脱LӞq入一U无序的、؜q状态。没有文档可参考,意味着很多问题只能问hQ而不同h的回{可能各异,同一个h对同一个问题的两次回答也可能不同!当然Q如果整个团队的工程素养和个体的职业?fn)惯都比较好的情况下可能不?x)发生cM的情c(din)?font color="#ff0000">但是q种工程素养和职业习(fn)惯从哪里来,可能单靠的XP是不以培养出来的?/strong>

“UP是正PXP是草书。要先学好UP才能学好XPQ先学XP?x)ؕ套。”这句话表明?jin)UP和XP在一定程度上是存在冲H的Qƈ且提Z(jin)一条\U去降低和避免这个冲H?/p>

再次需要强调的是庄兄所提到的“XP是一U思想”,q点我认同。但是我认ؓ(f)q个除了(jin)思想之外Q还是一U“文化”。这U思想和文化也是出于Y件工E多q来的实践,其中也不免有UP{其他过E。不能简单地认ؓ(f)“我们只要吸取历史的教训Q提出新的思想和文化就不会(x)再犯同样的错误了(jin)。”很多时候历史L一ơ又一ơ地重演着?font color="#ff0000">新的思想和文化如果不能被准确地理解和q用Q它所带来的可能仍然是它原本想解决的问题。只有我们具备了(jin)引入q种文化的基Q才能把它变成自q文化Q否则这仍然是挂在嘴边行于表面的一U不求精髓只求模仿的伪文化、伪思想。这一点对于UP和XP的实践者来说没有什么两栗?/strong>



GHawk 2006-04-25 15:03 发表评论
]]>
UP & XP之争Q意义何在?http://www.aygfsteel.com/ghawk/archive/2006/04/23/42691.htmlGHawkGHawkSun, 23 Apr 2006 10:28:00 GMThttp://www.aygfsteel.com/ghawk/archive/2006/04/23/42691.htmlhttp://www.aygfsteel.com/ghawk/comments/42691.htmlhttp://www.aygfsteel.com/ghawk/archive/2006/04/23/42691.html#Feedback4http://www.aygfsteel.com/ghawk/comments/commentRss/42691.htmlhttp://www.aygfsteel.com/ghawk/services/trackbacks/42691.html不光是做软gQ凡是做产品Q最后关注的L产品?font color="#ff0000">质量?/p>

举个例子Q比如你做一锅汤Q?br />今天你状态很好,做完后尝?jin)尝Q感觉很味Q你的家人尝?jin)以后也有同感,喝完后感觉?j)情舒畅、意Ҏ(gu)?br />隔了(jin)一个礼拜,你做同样的汤l家里h喝。做完后你尝?jin)尝Q感觉依然美呻I盼望着得到家h的赏识,然而他们却说味道咸?jin)点。你很奇怪,Z么同栯己尝q了(jin)Q家里h却感觉不一样呢Q是不是最q加班多?jin),休息不好Q味觉不准了(jin)Q?br />一个月q后Q你要去国外出差Q给安请了(jin)个(f)时保姆。一天,他也做了(jin)q么个汤Q做完后Q他也尝?jin)尝Q感觉口呛_不错Q可是端上桌Q家里h说这汤太辣了(jin)。原来这保姆才从湖南老家出来不久…?/p>

因此Q只把焦Ҏ(gu)在最后的产品上往往是不够的。需要对“做汤的q程”加以控制。所以工E界?x)比较关注过E的理Q在软g领域也称作“Y件生命周期管理”?/p>

再来看看UP和XP。它们都属于软gq程Q只不过各有特色?/p>

再拿刚才那个做汤的例子:(x)
大家都听说过德国人的厨房像化学实验室Q天q뀁计时器、量杯……装备齐全,再配上精的菜谱Q严谨的德国够确保不用尝那最后一口都做出口味基本一致的汤?br />换了(jin)中国人,大部分h都不?x)模仿d国h做菜的方式。解x(chng)案很单,让你的太太和孩子都尝那最后一口,再根据反馈调整几ơ,同样能做出全家h满意的汤?/p>

q个例子也许不太贴切Q但是可以联想一?德国人做汤們֐于UP;中国人做汤們֐于XP?/p>

UP和XP最l目的都是ؓ(f)?jin)保证品的质量Q不同的是,两个q程所的方法不同。我惻I没有Z(x)说“UP的目的在于变态地q求文档的完”、“UP是ؓ(f)?jin)要E序员学?x)写各种各样文档”……之cȝ话。同Ӟ也没Z(x)说“XP是不要文档只要代码”、“XP是要变态地q求完美的代码”……这L(fng)话?/p>

q些不正的看法Q只是h们对于这两种q程的误解。或许是来自于开发h员和目l理的那些“不堪回首的l历”?/p>

“UPx(chng)?jin)整个Y件行业,让开发h员没完没?jin)地写文档而忽略了(jin)代码QXP才是王道”这L(fng)话,我不敢苟同,仍然有很多企业用着UPq样的重型Y件工E,好比d国h依然喜欢把厨房弄得像个实验室?/p>

XP固然是个好东ѝ但是,不知道大多数人对于XP的热hZ对XP文化的理解,q是国h惯有的“一H蜂”似的行为?font color="#ff0000">不晓得一个“能够熟l阅M码的Leader”是不是能够真正q用好XPQ确保他的团队能够尽可能地出现"Over engineering"q种q背Agile_的东西,或是能够让他的团队保证“每周只工作40时”这L(fng)基本实践Q?/strong>

对于不同的技术和q程Q应该给予冷?rn)的分析和慎重的选择。每个过E和技术都不能以“正”或“不正确”来定性,只能以“合适”和“不合适”来定性。因为正或不正是要严D明的Q而合适不合适是来源于工E实늚l果。所以,COBOL依然在金融领域v着举轻重的作用,U学家们仍不忘FortranQ汇~和C仍然健在…?/p>

另外不得不提的是文化上的差异。ؓ(f)什么很多时候,我们学习(fn)国外的先q技术,购买?jin)整套生产线Q引q了(jin)全套囄Q请国外专家做了(jin)详细的全E化培训Q国人生产出的品品质依然不如国外原产的Q这是每个中国h都应该思考的问题…?/p>

 (tng)



GHawk 2006-04-23 18:28 发表评论
]]>
?UP是正PXP是草?的反?/title><link>http://www.aygfsteel.com/ghawk/archive/2006/03/01/33025.html</link><dc:creator>GHawk</dc:creator><author>GHawk</author><pubDate>Wed, 01 Mar 2006 08:25:00 GMT</pubDate><guid>http://www.aygfsteel.com/ghawk/archive/2006/03/01/33025.html</guid><wfw:comment>http://www.aygfsteel.com/ghawk/comments/33025.html</wfw:comment><comments>http://www.aygfsteel.com/ghawk/archive/2006/03/01/33025.html#Feedback</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.aygfsteel.com/ghawk/comments/commentRss/33025.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/ghawk/services/trackbacks/33025.html</trackback:ping><description><![CDATA[ <p>“UP是正PXP是草书。先学好?jin)UPQ才能学好XPQ先学XP再学UP׃(x)乱套。?tng)?</p> <p> </p> <p>老师曾这么说。最q,对这句话有了(jin)深刻的体?x)?</p> <p>软gq程是一个以Zؓ(f)中心(j)的活动。h是项目中最隄定和控制的因素。休息的质量、情l的起伏都会(x)影响整个zd。ؓ(f)?jin)尽可能地约束这U个体的不确定行为和减少开发过E中不必要的误会(x)?UP"采用?jin)大量的文档来对整个开发过E进行控制。这些文档主要分Z下几c:(x) </p> <ul> <li>计划文档——项目的开发计划、P代计划、测试计划等? </li> <li>技术文档——项目的设计文档、某个操作的说明文档{? </li> <li>记录文档——日常的?x)议U要、每日进度反馈、评估报告等?</li> </ul> <p>文档成了(jin)UPzd的主要部分。在UP中,往往大量的资源用于文档的制作。这些文档的目的是ؓ(f)?jin)尽可能减少不必要的沟通成本和误会(x)Q也Z(jin)在发生问题的时候能够尽快确定原因找到解x(chng)法?</p> <p> </p> <p>而正是因为如此繁重的资源消耗,D真正的设计和代码只占C(jin)d销的很部分。这对很多h来说不可理解Q甚臌得本末倒置。于是很多敏h法诞生了(jin)Q最具代表性也是对UP思想最具颠覆性的属XP?jin)?</p> <p> </p> <p>对外QXP以快速的反应速度来响应客L(fng)需求;对内QXP以高质量的代码和设计来确保尽可能不生不必要的文档和资源开销?</p> <p> </p> <p>从表面上看,在当今,XP实是一U非常理想的开发过E?</p> <p> </p> <p>但是Q从没有q程到XP往往?x)非常失败。这是ؓ(f)什么?问题的关键还在于人?</p> <p> </p> <ul> <li>无过E?->UP -->XP </li> </ul> <p>UP利用文档来约束和规范Z的开发活动。当一个没有经验的团队l历UP后,q于把性格各异、习(fn)惯差别不同的?font color="#a52a2a">l一</font>成了(jin)“相对较一致的开发h员”?</p> <p>他们有一致的~码?fn)惯Q有共同的用语,有严格的规则。随着l验的积累,q个团队间的默契来高。此Ӟ如果q程由UP向XP切换Q付出的代h(hun)׃(x)相对较低?</p> <p> </p> <ul> <li>无过E?->XP-->UP </li> </ul> <p>XPd快速反应。如果一个没有经验的团队在一开始就试XPQ那么后果可能是惨痛的。因Z个没有经验的团队其成员间的相互了(jin)解颇,对于一件事Q往往十个人有十种x(chng)。当~少文档U束Ӟ在以代码和设计ؓ(f)中心(j)的活动中Q成员(sh)间往往因ؓ(f)水^的参差不齐导致无休止的讨论甚至争论,代码被不必要地频J改动。这是因为,<font color="#ff0000"><strong>在团队徏设早期,成员?sh)间往往q最基本的尊重和信Q都不存在?/strong></font> q种无意义的zd往往?x)严重?jing)响项目的正常q行?</p> <p> </p> <p>所以,学习(fn)和应用过E不仅仅是个体的事,而是整个团队的事。只有当团队采用严格文档化的q程q且l过合后,才能渐渐向轻量的过E迁U,逐渐不必要的文档删减掉Q采用更灉|的过E。但是,此时q不是“没有文档”而是“心(j)中有文档”?/p> <img src ="http://www.aygfsteel.com/ghawk/aggbug/33025.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/ghawk/" target="_blank">GHawk</a> 2006-03-01 16:25 <a href="http://www.aygfsteel.com/ghawk/archive/2006/03/01/33025.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>敏捷软g开?MW记 Q?Q——OO五大原则Q?.LSP——里氏替换原则)(j) http://www.aygfsteel.com/ghawk/archive/2006/01/18/28545.htmlGHawkGHawkWed, 18 Jan 2006 10:12:00 GMThttp://www.aygfsteel.com/ghawk/archive/2006/01/18/28545.htmlhttp://www.aygfsteel.com/ghawk/comments/28545.htmlhttp://www.aygfsteel.com/ghawk/archive/2006/01/18/28545.html#Feedback2http://www.aygfsteel.com/ghawk/comments/commentRss/28545.htmlhttp://www.aygfsteel.com/ghawk/services/trackbacks/28545.htmlOCP作ؓ(f)OO的高层原则,d使用“抽?Abstraction)”和“多?Polymorphism)”将设计中的?rn)态结构改为动态结构,l持设计的封闭性?

“抽象”是语言提供的功能。“多态”由l承语义实现?

如此Q问题(sh)生了(jin)Q“我们如何去度量l承关系的质量??

Liskov?987q提Z(jin)一个关于承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“承必ȝ保超cL拥有的性质在子cM仍然成立。”也是_(d)当一个子cȝ实例应该能够替换M其超cȝ实例Ӟ它们之间才具有is-A关系?

该原则称为Liskov Substitution Principle——里氏替换原则。林先生在上课时风趣地称之ؓ(f)“老鼠的儿子会(x)打洞”。^_^

我们来研I一下LSP的实质。学?fn)OO的时候,我们知道Q一个对象是一l状态和一pd行ؓ(f)的组合体。状态是对象的内在特性,行ؓ(f)是对象的外在Ҏ(gu)。LSP所表述的就是在同一个承体pM的对象应该有共同的行为特征?

q一点上Q表明了(jin)OO的承与日常生活中的l承的本质区别。D一个例子:(x)生物学的分类体系中把企鹅归属为鸟cR我们模仿这个体p,设计?gu)L(fng)cd关系?

 lsp-fig1.jpg

cZ鸟”中有个Ҏ(gu)flyQ企鹅自然也l承?jin)这个方法,可是企鹅不能飞阿Q于是,我们在企鹅的cM覆盖?jin)flyҎ(gu)Q告诉方法的调用者:(x)企鹅是不?x)飞的。这完全W合常理。但是,q违反了(jin)LSPQ企鹅是鸟的子类Q可是企鹅却不能飞!需要注意的是,此处的“鸟”已l不再是生物学中的鸟?jin),它是软g中的一个类、一个抽象?

有h?x)说Q企鹅不能飞很正常啊Q而且q样~写代码也能正常~译Q只要在使用q个cȝ客户代码中加一句判断就行了(jin)。但是,q就是问题所在!首先Q客户代码和“企鹅”的代码很有可能不是同时设计的,在当今Y件外包一层又一层的开发模式下Q你甚至Ҏ(gu)不知道两个模块的原地是哪里Q也p不上M改客户代码了(jin)。客L(fng)序很可能是遗留系l的一部分Q很可能已经不再l护Q如果因计出q么一个“企鹅”而导致必M改客户代码,谁应该承担这部分责Q呢?Q大概是上帝吧,谁叫他让“企鹅”不能飞的。^_^Q“修改客户代码”直接违反了(jin)OCPQ这是OCP的重要性。违反LSP既有的设计不能封闭!

修正后的设计如下Q?

 lsp-fig2.jpg

但是Q这是LSP的全部了(jin)么?书中l了(jin)一个经典的例子Q这又是一个不W合常理的例子:(x)正方形不是一个长方Ş。这个?zhn)论的详细内容能在|上扑ֈQ我׃多废话了(jin)?

LSPq没有提供解册个问题的Ҏ(gu)Q而只是提Z(jin)q么一个问题?

于是Q工E师们开始关注如何确保对象的行ؓ(f)?988q_(d)B. Meyer提出?jin)Design by ContractQ契U式设计Q理论。DbC从Ş式化Ҏ(gu)中借鉴?jin)一套确保对象行为和自n状态的Ҏ(gu)Q其基本概念很简单:(x)

  1. 每个Ҏ(gu)调用之前Q该Ҏ(gu)应该校验传入参数的正性,只有正确才能执行该方法,否则认ؓ(f)调用方违反契U,不予执行。这UCؓ(f)前置条g(Pre-condition)?
  2. 一旦通过前置条g的校验,Ҏ(gu)必须执行Qƈ且必ȝ保执行结果符合契U,q称之ؓ(f)后置条g(Post-condition)?
  3. 对象本n有一套对自n状态进行校验的(g)查条Ӟ以确保该对象的本质不发生改变Q这UCZ变式(Invariant)?/LI>

以上是单个对象的U束条g。ؓ(f)?jin)满LSPQ当存在l承关系Ӟ子类中方法的前置条g必须与超cM被覆盖的Ҏ(gu)的前|条件相同或者更宽松Q而子cMҎ(gu)的后|条件必M类中被覆盖的方法的后置条g相同或者更Z根{?

一些OO语言中的Ҏ(gu)能够说明这一问题Q?

  • l承q且覆盖类Ҏ(gu)的时候,子类中的Ҏ(gu)的可见性必ȝ于或者大于超cM的方法的可见性,子类中的Ҏ(gu)所抛出的受(g)异常只能是超cM对应Ҏ(gu)所抛出的受(g)异常的子cR?
    public class SuperClass{
        
    public void methodA() throws IOException{}
    }


    public class SubClassA extends SuperClass{
        
    //this overriding is illegal.
        private void methodA() throws Exception{}
    }


    public class SubClassB extends SuperClass{
        
    //this overriding is OK.
        public void methodA() throws FileNotFoundException{}
    }

  • 从Java5开始,子类中的Ҏ(gu)的返回g可以是对应的类Ҏ(gu)的返回值的子类。这叫做“协变?Covariant)
    public class SuperClass {
        
    public Number caculate(){
            
    return null;
        }

    }


    public class SubClass extends SuperClass{
        
    //only compiles in Java 5 or later.
        public Integer caculate(){
            
    return null;
        }

    }

可以看出Q以上这些特性都非常好地遵@?jin)LSP。但是DbC呢?很遗憾,L的面向对象语aQ不论是动态语aq是?rn)态语aQ还没有加入对DbC的支持。但是随着AOP概念的生,怿不久DbC也将成ؓ(f)OO语言的一个重要特性之一?

一些题外话Q?

前一阵子《敲响OO时代的钟》和《钟ؓ(f)谁而鸣?/A>两篇文章引来?jin)无数议论。其中提C(jin)不少OO语言的不뀂事实上Q遵从LSP和OCPQ不是?rn)态类型还是动态类型系l,只要是OO的设计,应该对对象的行为有严格的约束。这个约束ƈ不仅仅体现在Ҏ(gu){֐上,而是q个具体行ؓ(f)的本w。这才是LSP和DbC的真谛。从q一Ҏ(gu)说ƈ不能说明“万事万物皆对象”的动态语a和“C++QJava”这U“按接口~程”语a的优劣,两类语言都有待于改进。庄兄对DJ的设惛_是开始引入DbC的概念了(jin)。这一点还是非常值得期待的。^_^
另外Q接口的语义正被OCP、LSP、DbCq样的概念不断地强化Q接口表达了(jin)对象行ؓ(f)之间的“契U”关pR而不是简单地作ؓ(f)一U实现多l承的语法糖?/P>

GHawk 2006-01-18 18:12 发表评论
]]>
敏捷软g开?MW记 Q?Q——OO五大原则Q?.OCP——开闭原则)(j)http://www.aygfsteel.com/ghawk/archive/2006/01/18/28394.htmlGHawkGHawkTue, 17 Jan 2006 16:26:00 GMThttp://www.aygfsteel.com/ghawk/archive/2006/01/18/28394.htmlhttp://www.aygfsteel.com/ghawk/comments/28394.htmlhttp://www.aygfsteel.com/ghawk/archive/2006/01/18/28394.html#Feedback6http://www.aygfsteel.com/ghawk/comments/commentRss/28394.htmlhttp://www.aygfsteel.com/ghawk/services/trackbacks/28394.html开闭原则很单,一句话Q“Closed for Modification; Open for Extension”——“对变更关闭Q对扩展开䏀。开闭原则其实没什么好讲的Q我其归结Z个高层次的设计d。就q一Ҏ(gu)ԌOCP的地位应该比SRP优先?

OCP的动机很单:(x)软g是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明?jin)Y件设计应该尽可能C架构E_而又Ҏ(gu)满不同的需求?

Z么要OCPQ答案也很简单——重用?

“重用”,q不是什么Y件工E的专业词汇Q它是工E界所q的词汇。早在Y件出现前Q工E师们就在实践“重用”了(jin)。比如机C品,通过雉件的l装得到最l的能够使用的工兗由于机械部件的设计和制造过E是极其复杂的,所以互换性是一个重要的Ҏ(gu)。一辆R可以用不同的发动机、不同的变速箱、不同的轮胎……很多东西我们直接买来装上就可以?jin)。这也是一个OCP的例子。(可能是由于我是搞机械?gu)n的吧Q所以就举些机械斚w的例子^_^Q?

如何在OO中引入OCP原则Q把对实体的依赖改ؓ(f)Ҏ(gu)象的依赖p?jin)。下面的例子说明?jin)这个过E:(x)

05赛季的时候,一辆F1赛R有一台V10引擎。但是到?6赛季Q国际汽联修改了(jin)规则Q一辆F1赛R只能安装一台V8引擎。R队很快投入了(jin)新赛车的研发Q不q的是,从工E师那里得到消息Q旧车n的设计不能够装进新研发的引擎。我们不得不为新的引擎重新打造Rw,于是一辆新的赛车诞生了(jin)。但是,ȝ(ch)的事接踵而来Q国际汽联频频修改规则,搞得设计师在“赛车”上改了(jin)又改Q最l变得不成样子,只能把它废弃?

OCP-fig1.JPG

Z(jin)能够重用q辆昂贵的赛车,工程师们提出?jin)解x(chng)案:(x)首先Q在车n的设计上预留出安装引擎的位置和管Uѝ然后,Ҏ(gu)q些设计好的规范设计引擎Q或是引擎的适配器)(j)。于是,新的赛R设计Ҏ(gu)p栯生了(jin)?

 OCP-fig2.JPG

昄Q通过重构Q这里应用的是一个典型的Bridge模式。这个实现的关键之处在于我们预先l引擎留Z(jin)位置Q我们不必因为对引擎的规则的频频变更而制造相当多的Rw,而是可能地沿用和改良现有的车n?BR>说到q里Q想说一说OO设计的一个误区?BR>学习(fn)OO语言的时候,Z(jin)能够说明“扎(k)(或者说“is-a”)(j)q个概念Q教U书上经常用实际生活中的例子来解释。比如汽车是车,?sh)R是RQF1赛R是汽车,所以R是汽车、电(sh)车、F1赛R的上层抽象。这个例子ƈ没有错。问题是Q这L(fng)例子q于“Ş象”了(jin)Q如果OO设计直接可以将现实生活中的概念引用q来Q那也就不需要什么Y件工E师?jin)!OO设计的关键概忉|抽象。如果没有抽象,那所有的软g工程师的努力都是徒劳的。因为如果没有抽象,我们只能L造世界中每一个对象。上面这个例子中Q我们应该看到“引擎”这个抽象的存在Q因R队的工程师们为它预留?jin)位|,为它制定?jin)设计规范?BR>上面q个设计也实C(jin)后面要说的DIPQ依赖倒置原则Q。但是请CQOCP是OO设计原则中高层次的原则,其余的原则对OCP提供?jin)不同程度的支持。ؓ(f)?jin)实现OCPQ我们会(x)自觉或者不自觉地用到其它原则或是诸如Bridge、Decorator{设计模式。然而,对于一个应用系l而言Q实现OCPq不是设计目的,我们所希望的只是一个稳定的架构。所以对OCP的追求也应该适可而止Q不要陷入过渡设计。正如Martin本h所_(d)(x)“No significant program can be 100% closed.”“Closure not complete but strategic?BR>
Q下一就要讲LSP?jin),我觉得这是意义最为重要的OO设计原则Q它直指当今LOO语言的Y肋,点出?jin)OO设计的精髓。)(j)



GHawk 2006-01-18 00:26 发表评论
]]>
敏捷软g开?MW记 Q?Q——OO五大原则Q?.SRP 单一职责原则Q?/title><link>http://www.aygfsteel.com/ghawk/archive/2006/01/09/27312.html</link><dc:creator>GHawk</dc:creator><author>GHawk</author><pubDate>Mon, 09 Jan 2006 13:17:00 GMT</pubDate><guid>http://www.aygfsteel.com/ghawk/archive/2006/01/09/27312.html</guid><wfw:comment>http://www.aygfsteel.com/ghawk/comments/27312.html</wfw:comment><comments>http://www.aygfsteel.com/ghawk/archive/2006/01/09/27312.html#Feedback</comments><slash:comments>4</slash:comments><wfw:commentRss>http://www.aygfsteel.com/ghawk/comments/commentRss/27312.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/ghawk/services/trackbacks/27312.html</trackback:ping><description><![CDATA[<P>      一点说明:(x)OO的五大原则是指SRP、OCP、LSP、DIP、ISP。这五个原则是书中所提到的。除此之外,书中q提C些高层次的原则用于组l高层的设计元素Q这些放Cơ再写。当?dng)OO设计的原则可能不止这五个Q希望大家多提宝贉|见,多多交流?/P> <P>      在学?fn)和使用OO设计的时候,我们应该明白QOO的出C得Y件工E师们能够用更接q真实世界的Ҏ(gu)描述软gpȝ。然而,软g毕竟是徏立在抽象层次上的东西Q再怎么接近真实Q也不能替代真实或被真实替代?/P> <P>      OO设计的五大原则之间ƈ不是怺孤立的。彼此间存在着一定关联,一个可以是另一个原则的加强或是基础。违反其中的某一个,可能同时q反?jin)其余的原则。因此应该把q些原则融会(x)贯通,牢记在心(j)Q?/P> <P>1. SRPQSingle Responsibility Principle 单一职责原则Q?BR>      单一职责很容易理解,也很Ҏ(gu)实现。所谓单一职责Q就是一个设计元素只做一件事。什么是“只做一件事”?单说是管闲事。现实中是如此Q如果要你专?j)做一件事情,M人都有信?j)可以做得很(gu)。但如果Q你整天被ؕ七八p的事所累,q有?j)思和_֊把每件事都作好么Q?BR><IMG height=250 alt=fig-1.JPG src="http://www.aygfsteel.com/images/blogjava_net/ghawk/OOD/fig-1.JPG" width=127 align=left border=0><BR>     “单一职责”就是要在设计中为每U职责设计一个类Q彼此保持正交,互不q涉。这个雕塑(二重奏)(j)是正交的一个例子,钢琴家和提琴家各自演奏自己的乐谱,而结果就是一个和谐的交响乐。当?dng)真实世界中,演奏提琴和弚(x)w琴的必须是两个hQ但是在软g中,我们往往?x)把两者甚x(chng)多搅和到一P很多时候只是ؓ(f)?jin)方便或是最初设计的时候没有想到?nbsp;<BR><BR>      q样的例子在设计中很常见Q书中就l了(jin)一个很好的例子Q调制解调器。这是一个调制解调器最基本的功能。但是这个类事实上完成了(jin)两个职责Q连接的建立和中断、数据的发送和接收。显?dng)q违反了(jin)SRP。这样做?x)有潜在的问题?x)当仅需要改变数据连接方式时Q必M改Modemc,而修改Modemcȝl果是使得M依赖Modemcȝ元素都需要重新编译,不管它是不是用到?jin)数据连接功能。解决的办法Q书中也已经l出Q重构Modemc,从中抽出两个接口Q一个专门负责连接、另一个专门负责数据发送。依赖Modemcȝ元素也要做相应的l化Q根据职责的不同分别依赖不同的接口。最后由ModemImplementationcd现这两个接口?BR><IMG height=258 alt=fig-2.JPG src="http://www.aygfsteel.com/images/blogjava_net/ghawk/OOD/fig-2.JPG" width=661 border=0> <P>      从这个例子中Q我们不隑֏玎ͼq反SRP通常是由于过于“真实”地设计?jin)一个类所造成的。因此,解决办法是往更高?sh)层进行抽象化提取Q将Ҏ(gu)个具体类的依赖改变(sh)ؓ(f)对一l接口或抽象cȝ依赖。当?dng)q个抽象化的提取应该Ҏ(gu)需要设计,而不是盲目提取。比如刚才这个Modem的例子中Q如果有必要Q还可以把DataChannel抽象为DataSender和DataReceiver两个接口?BR> </P><img src ="http://www.aygfsteel.com/ghawk/aggbug/27312.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/ghawk/" target="_blank">GHawk</a> 2006-01-09 21:17 <a href="http://www.aygfsteel.com/ghawk/archive/2006/01/09/27312.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>敏捷软g开?MW记 Q序——废话)(j)http://www.aygfsteel.com/ghawk/archive/2005/12/27/25553.htmlGHawkGHawkTue, 27 Dec 2005 04:00:00 GMThttp://www.aygfsteel.com/ghawk/archive/2005/12/27/25553.htmlhttp://www.aygfsteel.com/ghawk/comments/25553.htmlhttp://www.aygfsteel.com/ghawk/archive/2005/12/27/25553.html#Feedback2http://www.aygfsteel.com/ghawk/comments/commentRss/25553.htmlhttp://www.aygfsteel.com/ghawk/services/trackbacks/25553.html7-5083-1503-0l.gif

最q正在读q本书,喜欢影印版,是因Z中漂亮的插图。:(x)Q惭愧,如此的好书到现在才去诅R?BR>准备边读边记录些?j)得Q今天先说些废话。:(x)P

先粗略地概览?jin)一遍全书。本书主要分以下几个部分Q?

  1. 敏捷软gq程。主要以XPZ。这部分的最后一章,用一个对话式的小故事讲述?jin)一个非常小的过E。给?jin)读者关于敏捯E的形象化的认识?/LI>
  2. 敏捷设计。这部分是个很大的看炏V它讲述?jin)设计中一些常见的问题Q及(qing)其应对(用几个经典的设计原则Q?/LI>
  3. 案例实践。讲qC(jin)如何利用设计模式d늬二部分中提到的设计原则和避免设计中的“味道”?/LI>

之所以觉得这本书好,q(sh)一个h有关。就是交大Y件学院的林d彰老师。林先生的课Q风幽默,能够用直观Ş象的语言让学生对讲课内容产生深刻的印象。(我可不是托儿Q网上能搜到些林先生讲课的片断,要是怀疑,可以验证一番)(j)。记得在软g工程q门NQ林先生l我们讲?jin)很多有兌计原则的内容Q其中就有“开闭原则(OCPQ”、“里氏替换原则(LSPQ”等……就把这本书当作是一本补充读物吧?

a归正传。个人感觉这本书的M风格Q就和所要讲的“敏捷”一Pq不带着厚重的学院派风味Q而是更注重实c(din)ƈ不是没有理论Q只是把理论融入C(jin)实践中,化了(jin)理论的复杂性。读h感觉很带劲儿?

废话说到q里Q下一步的计划是跟着自己的进度写M?j)得了(jin)。我x(chng)对书中内容的理解和以前在林先生的课上所学的l合在一P导出阅读此书时的大脑zd镜像?/P>

GHawk 2005-12-27 12:00 发表评论
]]>
q程的代?/title><link>http://www.aygfsteel.com/ghawk/archive/2005/12/14/23772.html</link><dc:creator>GHawk</dc:creator><author>GHawk</author><pubDate>Wed, 14 Dec 2005 01:57:00 GMT</pubDate><guid>http://www.aygfsteel.com/ghawk/archive/2005/12/14/23772.html</guid><wfw:comment>http://www.aygfsteel.com/ghawk/comments/23772.html</wfw:comment><comments>http://www.aygfsteel.com/ghawk/archive/2005/12/14/23772.html#Feedback</comments><slash:comments>5</slash:comments><wfw:commentRss>http://www.aygfsteel.com/ghawk/comments/commentRss/23772.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/ghawk/services/trackbacks/23772.html</trackback:ping><description><![CDATA[<P>q个月刚q入公司Q加入了(jin)一?0人左右的团队Q用Java做一个网站后台?BR><BR>客户是日本公司,他们做了(jin)目的大部分分析(Requirements, Use cases, Domain model...)。我们负责的是详l设计和开发。我是项目开始几星期后才q的公司。Schedule也已lؓ(f)我分配好?jin)。大安按照schedule上的安排工作着?BR><BR>上星期开?x)的时候得知,日本q次采用的是agileq程。而我们的schedule更类gRUPq样的过E。RUPq个学院z֒Agileq个造反z路相逢,问题?sh)就出现了(jin)?BR><BR>大家工作都很卖力Qؓ(f)?jin)能按进度提交制品,有时q通宵达旦解决问题。我们这支团队的战斗力和信心(j)是不Ҏ(gu)疑的。可是大家努力的l果换来的却是用L(fng)抱怨。大安困惑不解。问题究竟出在哪儿?<BR><BR>日方在项目中的是Agileq程Q我们采用的则是传统的过E。一开始,两个q程Ҏ(gu)之间的差异ƈ不大Q对我们提交的制品,客户也没有什么异议。但是,直到客户提出问题?sh)前Q我们所提交的制品都是一些设计文档。而我们的制品也仅限于此——没有一个可用的EAR包、没有写q?test case。很明显Q我们犯?jin)agile的大忌?BR><BR>Agile所的是快速的构徏、轻量的P代、TDD{。由于之前没有写test caseQ详l设计也没有test case可以参照。设计本w是不是合理Q是不是testable也不得而知。致使在设计test case的时候无从下手,很多cȝ至都没有办法试。整个架构的可行性很难估?BR><BR>往后考虑。一ơ大规模的重构可能是不?jin)的。虽然agileq程本n提倡以TDD为基的重构。但是现在的重构可能造成的代价已l不是一ơ轻量的增量P代了(jin)?BR><BR>说到q里Qȝ几点Q希望能在以后的工作中引h意:(x)<BR>1. Agile很难理Q项目早期应该对各种风险有尽可能全面的评伎ͼschedule的设|中应该定义?test case ?build 的时间点?BR>2. 设计不必太详l,用频J的试和重构完善设计?BR>3. Test case 优先设计Q这样在架构中就?x)对testability有够多的考虑?BR>4. 团队内部对共同的N应该?qing)早q行讨论和解冻I问题的解x(chng)案应该传递到每个l员Q尽可能保证团队的能力同步?/P><img src ="http://www.aygfsteel.com/ghawk/aggbug/23772.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/ghawk/" target="_blank">GHawk</a> 2005-12-14 09:57 <a href="http://www.aygfsteel.com/ghawk/archive/2005/12/14/23772.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <a href="http://www.aygfsteel.com/" title="狠狠久久亚洲欧美专区_中文字幕亚洲综合久久202_国产精品亚洲第五区在线_日本免费网站视频">狠狠久久亚洲欧美专区_中文字幕亚洲综合久久202_国产精品亚洲第五区在线_日本免费网站视频</a> </div> </footer> վ֩ģ壺 <a href="http://" target="_blank">ɽ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">彧</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ˮ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ɽ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">Ƕ</a>| <a href="http://" target="_blank">ع</a>| <a href="http://" target="_blank">ֶ</a>| <a href="http://" target="_blank">ʤ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ٳ</a>| <a href="http://" target="_blank">ũ</a>| <a href="http://" target="_blank">Ҷ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ׯ</a>| <a href="http://" target="_blank">պ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ֽ</a>| <a href="http://" target="_blank">տ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ɽ</a>| <a href="http://" target="_blank">ˮ</a>| <a href="http://" target="_blank">˶</a>| <a href="http://" target="_blank">ֽ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ˮ</a>| <a href="http://" target="_blank">Դ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">̨ʡ</a>| <a href="http://" target="_blank">ᶫ</a>| <a href="http://" target="_blank">׷</a>| <a href="http://" target="_blank">ɳ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ǿ</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>