使用设计模式改善程序结构(三)
2008-01-05 09:35:47 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佽鍨庨崘锝嗗瘱闂備胶顢婂▍鏇㈠箲閸ヮ剙鐏抽柡鍐ㄧ墕缁€鍐┿亜韫囧海顦﹀ù婊堢畺閺屻劌鈹戦崱娆忓毈缂備降鍔庣划顖炲Φ閸曨垰绠抽悗锝庝簽娴犻箖姊洪棃娑欐悙閻庢矮鍗抽悰顕€宕堕澶嬫櫖濠殿噯绲剧€笛囧箲閸ヮ剙钃熼柣鏂挎憸閻熷綊鏌涢…鎴濇灈妞ゎ剙鐗嗛—鍐Χ鎼粹€茬凹缂備緡鍠楅幐鎼佹偩閻戣棄纭€闁绘劕绉靛Λ鍐春閳ь剚銇勯幒鎴濐伀鐎规挷绀侀埞鎴︽偐閹绘帩浼€缂佹儳褰炵划娆撳蓟濞戞矮娌柟瑙勫姇椤ユ繈姊洪柅鐐茶嫰婢т即鏌熼搹顐e磳闁挎繄鍋涢埞鎴犫偓锝庘偓顓涙櫊閺屽秵娼幏灞藉帯闂佹眹鍊曢幊鎰閹惧瓨濯撮柛鎾村絻閸撳崬顪冮妶鍡楃仸闁荤啿鏅涢悾鐑藉Ψ瑜夐崑鎾绘晲鎼粹剝鐏嶉梺缁樻尰濞叉﹢濡甸崟顖氱疀闂傚牊绋愮花鑲╃磽娴h棄鐓愭慨妯稿妿濡叉劙骞樼拠鑼槰闂佸啿鎼崐濠毸囬弶搴撴斀妞ゆ梻銆嬪銉︺亜椤撶偛妲婚柣锝囧厴楠炴帡骞嬮弮鈧悗濠氭⒑鐟欏嫭鍎楅柛妯衡偓鐔插徍濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩绾惧鏌熼崜褏甯涢柍閿嬪灦閵囧嫰骞掗崱妞惧缂傚倷绀侀ˇ閬嶅极婵犳氨宓侀柛鈩冪⊕閸婄兘鏌涘┑鍡楊伀妞ゆ梹鍔曢埞鎴︽倻閸モ晝校闂佸憡鎸婚悷锔界┍婵犲洦鍤冮柍鍝勫暟閿涙粓姊鸿ぐ鎺戜喊闁告瑥楠搁埢鎾斥堪閸喓鍘搁柣蹇曞仧绾爼宕戦幘璇茬疀濞达絽鎲¢崐顖炴⒑绾懎浜归悶娑栧劦閸┾偓妞ゆ帒鍟惃娲煛娴e湱澧柍瑙勫灴閹瑩寮堕幋鐘辨闂備礁婀辨灙闁硅姤绮庨崚鎺楀籍閸喎浠虹紓浣割儓椤曟娊鏁冮崒娑氬幈闂佸搫娲㈤崝宀勬倶閻樼粯鐓曢柟鑸妼娴滄儳鈹戦敍鍕杭闁稿﹥鐗犲畷婵嬫晝閳ь剟鈥﹂崸妤€鐒垫い鎺嶈兌缁犲墽鈧厜鍋撳┑鐘辩窔閸嬫鈹戦纭烽練婵炲拑绲垮Σ鎰板箳閹冲磭鍠撻幏鐘绘嚑閼稿灚姣愰梻鍌氬€烽懗鑸电仚濠电偛顕崗妯侯嚕椤愩倖瀚氱€瑰壊鍠栧▓銊︾節閻㈤潧校缁炬澘绉瑰鏌ュ箵閹烘繄鍞甸柣鐘烘鐏忋劌顔忛妷褉鍋撶憴鍕碍婵☆偅绻傞~蹇涙惞閸︻厾锛滃┑鈽嗗灠閹碱偊锝炲鍥╃=濞达綁顥撻崝宥夋煙缁嬪灝鏆遍柣锝囧厴楠炲鏁冮埀顒傜不婵犳碍鍋i柛銉戝啰楠囬悗瑙勬尭缁夋挳鈥旈崘顔嘉ч柛鈩兠棄宥囩磽娴e壊鍎愰柛銊ュ缁顓兼径瀣偓閿嬨亜閹哄秶顦︾€殿喖鐏濋埞鎴﹀煡閸℃浠梺鍛婎焼閸曨収娲告俊銈忕到閸燁垶宕愰崹顐e弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�

设计模式在某种程度上确实能够改善我们的程序结构,使设计具有更好的弹性。也正是由于这个原因,会导致我们可能过度的使用它。程序结构具有过度的、不必要的灵活性和程序结构没有灵活性一样都是有害的。本文将分析过度的灵活性可能造成的危害,并且结合一些实例来阐述使用设计模式改善程序结构应遵循的原则。
1、介绍
本系列文章的前两篇主要讲述了如何使用设计模式来改善我们的程序结构,大家可以看到经过调整的代码具有了更大的弹性,更轻易适应变化。读者朋友可能也具有类似的经验,通过使用设计模式使得自己的软件系统更加具有可扩展性和健壮性。但是,这样就可能会造成一个结果:无论碰到任何问题,我们首先做的就是设法找到一个解决它的设计模式来,而不是解决问题的最简洁的方法。
上面所述的就是过分使用设计模式的情况,它赋予了代码过度的灵活性。大家往往对于僵化、拙劣的设计所导致的危害非常清楚,但是对于过度灵活的设计可能带来的危害却不是很重视。本文试图从这个角度来谈谈使用设计模式改善程序结构应遵循的原则,使大家避免陷入过分使用设计模式的状况。其中的一个要害议题就是:我们为什么要使用设计模式,到底什么样的程序结构才是好的。
2、过分设计的危害
正是由于大家对于僵化的设计所造成的结果的惧怕,以及对于设计模式给我们的程序结构带来的无比的弹性的赞叹,才会导致过分的预先设计(up-front design)。原因很简单:需求肯定是要变化的。所以,我们就需要给代码一些更多的灵活性,使得它可以适应以后的变化。于是,我们在最开始的设计中,就针对需求的变化做了很多的假设,并把对于这些假设的支持放在代码中。
假如对这些假设的猜测是正确的,那么做的这一切都是值得的。不幸的是,对这些假设的猜测很难是正确的。原因很简单:需求是我们的客户(一般是另外一个企业)提出的,但是作为一个现代的企业,要想生存,就要不断的改变自己以适应日新月异的变化,所以客户的需求肯定是要根据自身生存、发展的需要而不断变化的,并且这些变化都是很难猜测的,经常是客户自己都不知道下一步该如何变化(假如都能够被你猜测到的话,这个公司肯定会高薪聘请你去做他们的CEO)。
假如猜测是错误的话,第一个直接后果就是,浪费了宝贵的时间、资金。我们花了很多的时间在一些根本没有任何用处的灵活性上,而这些时间本可以用来为系统增加新的功能或者修正错误。
过分灵活的代码往往更加复杂、难以理解。其他的开发人员不得不花费很多的时间来理解这些本来可以去除的复杂性。必然导致代码的维护、扩展困难(假如需求的变化和你的假设不同),项目的开发效率降低。
例如:发现一种计算有多个不同的方式, 不加思考就直接采用Strategy设计模式,而不是采用简单、清楚的条件表达式的方法(if-else语句),那么就会导致结构的复杂(要增加好几个类)。假如后来发现根本就没有在增加新的计算方法方面的需求,或者更糟糕的是需求的变化是某几个计算策略间要增加依靠关系,那么修改起来就会十分困难。系统中假如存在太多的这种没有必要的灵活性,很可能最终的程序结构就会陷入冗余、混乱之中。
程序结构的灵活性是有代价的,这种代价往往是更多的复杂性或者造成系统不轻易理解,需要我们在设计时进行权衡。
3、软件开发的节奏
现在在软件工程领域很活跃的一个组织是:灵敏社团,他们提出了一系列的灵敏方法(XP就是其中很闻名的一种)。在灵敏方法中制定了一系列的策略、实践来拥抱需求的变化。其目标是:使软件以规范的节奏进展,最终保质、按时交付软件产品。现在已有很多使用这种方法成功的商业案例。
对于软件开发的节奏可以描述如下:首先写测试代码,提出对于系统的功能需求,然后写工作代码满足这个需求,重复这个过程直到实现系统的所有需求。在这个过程中间要频繁的(一般是在增加新功能或者修正错误时)进行重构,去除冗余的、含糊的代码,改善程序的结构,使得新功能的添加变得轻易。可以看出在这样的软件开发节奏中,没有对需求的变化做什么猜测(进行猜测的主要原因是惧怕变化),而是以一种主动的姿态来拥抱变化,当目前的设计不能够适应发生的变化时,大胆的进行重构(因为有频繁测试保证,所以重构的风险是不大的)去适应新的变化。这种方式被称为演化设计(evolutionary design),在参考文献〔3〕中可以得到进一步的内容。
设计模式一般会成为重构的目标,但是为什么要这样做?我们一定要重构到一个设计模式吗?怎样的程序结构才是好的呢?
4、要害是要展现设计意图
现在有一个普遍的误解就是:程序结构的灵活性越高越好,所以对程序结构改善的目标就是使它具有更高的弹性,这样在未来需求发生变化时可以很轻易的改变程序来适应这种变化。其实,结构的灵活性和结构的易更改性之间是有矛盾的。很明显,结构越灵活相应的就会越复杂,越复杂就越不轻易理解,不轻易理解怎么会轻易更改呢?参考文献〔1〕中专门探讨了这个问题,有爱好可以看看。
正是这个误解的存在,使得很多开发者看到了设计模式所带给程序结构的灵活性,从而在进行代码重构时就把结构的灵活性作为一个最重要的目标。最终导致了程序结构的过分灵活性,损伤了软件的质量。
但是,设计模式确实能够改善我们的程序结构,面向对象大师Martin Fowler的经典著作《Refactoring ImPRoving the Design of Existing Code》一书中就有很多的使用设计模式进行重构的例子。难道仅仅是因为设计模式能够带来足够的灵活性吗?显然不是!主要是因为这些设计模式更能够展示设计者的设计意图,更加便于理解!
很多面向对象专家和模式研究专家对重构的动机进行了研究,发现对于一个好的重构过程来说,重构的结果到底是不是一个设计模式是不重要的。它们的最终动机都是:减少或者消除冗余代码,简化设计最终达到展示真正的设计意图,更加便于交流。
Martin Fowler的《Refactoring》一书的第一章有一个关于影碟出租的例子,具体的展示了重构的过程以及每一步的动机,很好的说明了上面的问题。
5、再谈设计模式的动机
本系列文章的第一篇中谈论设计模式本身的意图、动机的重要性。这里我想再结合上面的内容重新熟悉一下这个问题。现在我们有两个动机存在,设计模式本身的动机以及我们要重构来改善我们的程序结构的动机(可能是要重构到一个设计模式)。这两个动机其实是没有很大的关系的。
更多精彩
赞助商链接