軟件系統(tǒng)架構(gòu)設(shè)計(jì)知識(shí)講解

1、軟件系統(tǒng)架構(gòu)設(shè)計(jì)林國東Mail: 1第一頁，共235頁。目錄(ml)第一單元：軟件生命周期與軟件架構(gòu)介紹第一單元：軟件生命周期與軟件架構(gòu)介紹2第二單元：技術(shù)架構(gòu)視圖第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式 24用用GRASP模式指導(dǎo)設(shè)計(jì)模式指導(dǎo)設(shè)計(jì)27領(lǐng)域模型領(lǐng)域模型47面向?qū)ο笤O(shè)計(jì)的基本原則面向?qū)ο笤O(shè)計(jì)的基本原則71第三單元：用第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)輔助系統(tǒng)分析與設(shè)計(jì)103UML簡介簡介(jin ji)及常見疑難問題辨析及常見疑難問題辨析104借鑒借鑒RUP的的UML建模與分析建模與分析117第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想第四單元：設(shè)計(jì)模式與

2、軟件設(shè)計(jì)思想131設(shè)計(jì)模式設(shè)計(jì)模式132常用的軟件架構(gòu)風(fēng)格及適用情況分析常用的軟件架構(gòu)風(fēng)格及適用情況分析172SOA 及分層架構(gòu)設(shè)計(jì)及分層架構(gòu)設(shè)計(jì)212第五單元：架構(gòu)設(shè)計(jì)實(shí)踐第五單元：架構(gòu)設(shè)計(jì)實(shí)踐2252第二頁，共235頁。第一單元：軟件(run jin)生命周期與軟件(run jin)架構(gòu)介紹3第三頁，共235頁。 IT行業(yè)的人才結(jié)構(gòu)與軟件架構(gòu)師的定位(dngwi) 軟件架構(gòu)師應(yīng)掌握的知識(shí)體系 軟件架構(gòu)設(shè)計(jì)的特點(diǎn)、層次、分類 軟件架構(gòu)的主要理論、方向和趨勢(shì) 軟件工廠，實(shí)現(xiàn)軟件開發(fā)的產(chǎn)業(yè)化4第四頁，共235頁。軟件架構(gòu)師的定位(dngwi)系統(tǒng)架構(gòu)師的職責(zé)：一、理解系統(tǒng)的業(yè)務(wù)需求，制定系統(tǒng)的整

3、體框架（包括：技術(shù)框架和業(yè)務(wù)框架）二、對(duì)系統(tǒng)框架相關(guān)技術(shù)和業(yè)務(wù)進(jìn)行培訓(xùn)，指導(dǎo)開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運(yùn)行中出現(xiàn)的各種( zhn)問題。系統(tǒng)架構(gòu)師的目的：對(duì)系統(tǒng)的重用、擴(kuò)展、安全、性能、伸縮性、簡潔等做系統(tǒng)級(jí)的把握。系統(tǒng)架構(gòu)師能力要求：一、系統(tǒng)架構(gòu)相關(guān)的知識(shí)和經(jīng)驗(yàn)。二、很強(qiáng)的自學(xué)能力、分析能力、解決問題的能力。三、寫作、溝通表達(dá)、培訓(xùn)。5第五頁，共235頁。角色軟件架構(gòu)師Software Architect定義主導(dǎo)(zhdo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色6第六頁，共235頁。職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中的技術(shù)活動(dòng)（分析、設(shè)計(jì)和實(shí)施等）推動(dòng)主要的技術(shù)決策，并最終表達(dá)為

4、軟件構(gòu)架確定和文檔化系統(tǒng)的相對(duì)構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計(jì)、實(shí)施和部署等“視圖”確定設(shè)計(jì)元素的分組以及這些主要分組之間的接口為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關(guān)注點(diǎn)，化解技術(shù)風(fēng)險(xiǎn)，并保證相關(guān)決定被有效的傳達(dá)(chund)和貫徹理解、評(píng)價(jià)并接收系統(tǒng)需求評(píng)價(jià)和確認(rèn)軟件架構(gòu)的實(shí)現(xiàn)7第七頁，共235頁。專業(yè)技能技術(shù)全面、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富，具備在缺乏完整信息、眾多(zhngdu)問題交織一團(tuán)、模糊和矛盾的情況下，迅速抓住問題要害，并做出合理的關(guān)鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級(jí)別上進(jìn)行思考。對(duì)項(xiàng)目開發(fā)涉及的所有問題領(lǐng)域都有經(jīng)驗(yàn)，包括徹

5、底地理解項(xiàng)目需求，開展分析設(shè)計(jì)之類軟件工程活動(dòng)等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進(jìn)技術(shù)工作，并在項(xiàng)目壓力下做出牢靠的關(guān)鍵決策。擁有優(yōu)秀的溝通能力，用以進(jìn)行說服、鼓勵(lì)和指導(dǎo)等活動(dòng)，并贏得項(xiàng)目成員的信任。8第八頁，共235頁。以目標(biāo)導(dǎo)向和主動(dòng)的方式來不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)架師應(yīng)當(dāng)是項(xiàng)目背后的技術(shù)推動(dòng)力，而非構(gòu)想者或夢(mèng)想家（追求完美）精通構(gòu)架設(shè)計(jì)的理論、實(shí)踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機(jī)制和模式。具備系統(tǒng)設(shè)計(jì)員的所有技能(jnng)，但涉及面更廣、抽象級(jí)別更高。9第九頁，共235頁。軟件架構(gòu)師的知識(shí)(zh shi)體系軟件架構(gòu)師作為整個(gè)軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計(jì)師，其知識(shí)體系、

6、技能和經(jīng)驗(yàn)決定了軟件系統(tǒng)的可靠性、安全性、可維護(hù)性、可擴(kuò)展性和可移植性等方面的性能。因此一個(gè)優(yōu)秀的軟件架構(gòu)師必須具備相當(dāng)豐富的知識(shí)、技能和經(jīng)驗(yàn)。通過對(duì)比軟件架構(gòu)師和系統(tǒng)分析師在軟件開發(fā)中的職責(zé)和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識(shí)體系也是不盡相同的，系統(tǒng)分析師的主要職責(zé)是在需求分析、開發(fā)管理、運(yùn)行維護(hù)等方面，而軟件架構(gòu)師的重點(diǎn)工作是在架構(gòu)與設(shè)計(jì)這兩個(gè)關(guān)鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識(shí)體系中對(duì)系統(tǒng)的構(gòu)架(u ji)與設(shè)計(jì)等方面知識(shí)體系的要求就相對(duì)低些；而軟件架構(gòu)師在需求分析、項(xiàng)目管理、運(yùn)行維護(hù)等方面知識(shí)的要求也就相對(duì)低些。10第十頁，共235頁。成為一名合格的軟件架構(gòu)師必須具

7、備(jbi)的知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系11第十一頁，共235頁。？ MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-Service RSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRuby On Rails RupBPELWorkflow EngineLBS OracleCMMIMQ12第十二頁，共235頁。軟件架構(gòu)師在干什么？思考、思考、再思考深入理解、準(zhǔn)確把握建設(shè)的業(yè)務(wù)需求分析所有可見的問題、障礙、風(fēng)險(xiǎn)充分參考已有的成功方案，降低風(fēng)險(xiǎn)

8、交流、討論、博弈、質(zhì)疑對(duì)構(gòu)思中的方案不斷提出質(zhì)疑，避免漏洞廣泛(gungfn)聽取各層面的意見，開拓思路反復(fù)質(zhì)疑、逐步完善已有的設(shè)計(jì)構(gòu)思在動(dòng)手實(shí)現(xiàn)之前驗(yàn)證設(shè)計(jì)方案的正確性13第十三頁，共235頁。軟件架構(gòu)師的知識(shí)結(jié)構(gòu) 軟件知識(shí)(zh shi) 最好要有系統(tǒng)開發(fā)全過程經(jīng)驗(yàn)。 對(duì) IT 建設(shè)生命周期各個(gè)環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設(shè)計(jì)、物理設(shè)計(jì)、代碼開發(fā)、項(xiàng)目管理、測(cè)試、發(fā)布、運(yùn)行維護(hù)等。 深入掌握1-2種主流技術(shù)平臺(tái)上開發(fā)系統(tǒng)的方法。 了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)。 了解架構(gòu)設(shè)計(jì)領(lǐng)域的主要理論、流派、框架。14第十四頁，共235頁。軟件架構(gòu)師的知識(shí)結(jié)構(gòu) 業(yè)務(wù)知識(shí) 深入了解系統(tǒng)建設(shè)(jinsh)

9、的業(yè)務(wù)需求。 了解系統(tǒng)的非功能需求和運(yùn)行維護(hù)需求。 了解企業(yè) IT 公共設(shè)施、網(wǎng)絡(luò)環(huán)境、外部系統(tǒng)。15第十五頁，共235頁。軟件架構(gòu)師的思維(swi)方式基于框架的思維架構(gòu)設(shè)計(jì)的層次（Enterprise， Application， etc）IT 的生命周期（What， Why， Where， How， When， etc）成功經(jīng)驗(yàn)以及(yj)方法論的指導(dǎo)合理把握技術(shù)細(xì)節(jié)把握各個(gè)層次應(yīng)有的內(nèi)容合理忽略不應(yīng)有的技術(shù)細(xì)節(jié)16第十六頁，共235頁。軟件架構(gòu)師的思維(swi)方式 風(fēng)險(xiǎn)管理意識(shí) 采用成功經(jīng)驗(yàn)、避免不應(yīng)有的風(fēng)險(xiǎn) 多方位的開放思維 多維度、多方向、包容性、避免排他性 分析、質(zhì)疑、抽象、歸納

10、 沒有絕對(duì)好的架構(gòu)設(shè)計(jì)，只有相對(duì)(xingdu)優(yōu)秀的方案17第十七頁，共235頁。信息系統(tǒng)綜合(zngh)知識(shí)體系(1)計(jì)算機(jī)系統(tǒng)綜合知識(shí)：包括計(jì)算機(jī)組成與體系結(jié)構(gòu)、嵌入式系統(tǒng)和操作系統(tǒng)等方面(fngmin)的知識(shí)。(2)系統(tǒng)配置和方法：包括系統(tǒng)配置技術(shù)和系統(tǒng)性能等方面(fngmin)的知識(shí)。(3)典型系統(tǒng)應(yīng)用：包括網(wǎng)絡(luò)應(yīng)用、數(shù)據(jù)庫應(yīng)用和多媒體系統(tǒng)等方面(fngmin)的知識(shí)。(4)系統(tǒng)開發(fā)：包括程序設(shè)計(jì)語言、軟件開發(fā)方法、需求分析和設(shè)計(jì)方法、測(cè)試評(píng)審方法、開發(fā)管理、應(yīng)用系統(tǒng)構(gòu)建、系統(tǒng)審計(jì)、外部資源使用和基于中間件的開發(fā)等方面(fngmin)的知識(shí)。(5)安全性和可靠性技術(shù)：包括數(shù)據(jù)安全與保

11、密、防闖入和防病毒、容錯(cuò)技術(shù)、可靠性模型與分析技術(shù)、系統(tǒng)可靠性、安全規(guī)章和保護(hù)私有信息規(guī)則等方面(fngmin)的知識(shí)。18第十八頁，共235頁。(6)標(biāo)準(zhǔn)化：包括標(biāo)準(zhǔn)化的基礎(chǔ)知識(shí)、標(biāo)準(zhǔn)化分級(jí)、編碼標(biāo)準(zhǔn)、數(shù)據(jù)交換標(biāo)準(zhǔn)、軟件工程標(biāo)準(zhǔn)、信息安全標(biāo)準(zhǔn)、基于構(gòu)件的軟件標(biāo)準(zhǔn)和標(biāo)準(zhǔn)化組織機(jī)構(gòu)等方面的知識(shí)。(7)信息化基礎(chǔ)：包括政府信息化與電子政務(wù)、企業(yè)信息化與電子商務(wù)、信息化的有關(guān)的法律和規(guī)定等方面的知識(shí)。(8)數(shù)學(xué)和英語：至少具有(jyu)大學(xué)以上的數(shù)學(xué)和英語基礎(chǔ)知識(shí)。19第十九頁，共235頁。軟件架構(gòu)知識(shí)(zh shi)體系(1)系統(tǒng)計(jì)劃：包括項(xiàng)目的提出和可行性分析、系統(tǒng)方案的制定、評(píng)價(jià)和改進(jìn)、新舊系

12、統(tǒng)的分析與比較、現(xiàn)有軟、硬件和數(shù)據(jù)資源的有效利用等。(2)軟件架構(gòu)設(shè)計(jì)(shj)：包括軟件架構(gòu)的概念、軟件架構(gòu)與設(shè)計(jì)(shj)、架構(gòu)風(fēng)格、特定領(lǐng)域的架構(gòu)風(fēng)格、基于架構(gòu)的軟件開發(fā)方法、架構(gòu)評(píng)估、軟件產(chǎn)品線和系統(tǒng)演化等。(3)設(shè)計(jì)(shj)模式：包括設(shè)計(jì)(shj)模式的概念、組成、分類和實(shí)現(xiàn)、模式和軟件架構(gòu)的關(guān)系等。(4)系統(tǒng)設(shè)計(jì)(shj)：包括處理流程設(shè)計(jì)(shj)、人機(jī)界面設(shè)計(jì)(shj)、文件與存儲(chǔ)設(shè)計(jì)(shj)、數(shù)據(jù)庫設(shè)計(jì)(shj)、網(wǎng)絡(luò)應(yīng)用系統(tǒng)的設(shè)計(jì)(shj)、系統(tǒng)運(yùn)行環(huán)境的集成與設(shè)計(jì)(shj)、中間件與應(yīng)用服務(wù)器、性能設(shè)計(jì)(shj)與性能評(píng)估等。(5)軟件建模：包括定義問題與歸結(jié)模型、結(jié)

13、構(gòu)化系統(tǒng)建模與數(shù)據(jù)流圖、面向?qū)ο笙到y(tǒng)建模、數(shù)據(jù)庫建模和逆向工程等。20第二十頁，共235頁。(6)分布式系統(tǒng)設(shè)計(jì)：包括分布式通信協(xié)議的設(shè)計(jì)、基于對(duì)象與web的分布式設(shè)計(jì)、基于消息和協(xié)同的分布式設(shè)計(jì)和異構(gòu)分布式系統(tǒng)的互操作性設(shè)計(jì)等。(7)嵌入式系統(tǒng)設(shè)計(jì)：包括實(shí)施任務(wù)調(diào)度和多任務(wù)設(shè)計(jì)、中斷處理和異常處理、嵌入式系統(tǒng)開發(fā)設(shè)計(jì)等。(8)系統(tǒng)可靠性分析與設(shè)計(jì)：包括系統(tǒng)故障模型和可靠性模型、系統(tǒng)的可靠性分析與可靠度計(jì)算、提高系統(tǒng)可靠性的措施、系統(tǒng)的故障對(duì)策和系統(tǒng)的備份與恢復(fù)等。(9)系統(tǒng)的安全性和保密性設(shè)計(jì)：包括系統(tǒng)的訪問控制技術(shù)、數(shù)據(jù)的完整性、數(shù)據(jù)與文件(wnjin)的加密、通信的安全和系統(tǒng)的安全設(shè)計(jì)等

14、。(10)復(fù)雜架構(gòu)設(shè)計(jì)：包括操作系統(tǒng)的架構(gòu)、編譯器的架構(gòu)和大型基礎(chǔ)庫的架構(gòu)等。21第二十一頁，共235頁。軟件架構(gòu)師的任職(rn zh)條件根據(jù)軟件架構(gòu)師的職責(zé)和角色定位，以及知識(shí)體系，從實(shí)踐的角度考慮，合格的軟件架構(gòu)師應(yīng)該具有以下能力和經(jīng)驗(yàn)：(1)具有8年以上的軟件項(xiàng)目開發(fā)實(shí)際工作經(jīng)驗(yàn)，其中至少有3年以上的代碼編寫工作經(jīng)驗(yàn)，4年以上的基于面向?qū)ο蠛蜆?gòu)件開發(fā)方法的軟件產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)。 (2)具有5個(gè)以上大中型開發(fā)項(xiàng)目的總體規(guī)劃、方案設(shè)計(jì)經(jīng)驗(yàn)，有大中型應(yīng)用系統(tǒng)開發(fā)和實(shí)施(shsh)的成功案例。(3)對(duì)相關(guān)的技術(shù)標(biāo)準(zhǔn)有深刻的認(rèn)識(shí)，對(duì)軟件工程標(biāo)準(zhǔn)和規(guī)范有良好的把握。 (4)對(duì).Net或Java技術(shù)及整

15、個(gè)解決方案有深刻的理解及熟練的應(yīng)用，精通Web Service，熟練掌握流行的架構(gòu)。 22第二十二頁，共235頁。(5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品特性和質(zhì)量(zhling)屬性的框架。(6)具有面向?qū)ο蟮姆治?、設(shè)計(jì)和開發(fā)能力，精通UML和XML，能熟練使用Rational Rose、PowerDesigner等工具進(jìn)行設(shè)計(jì)。 (7)具有良好的團(tuán)隊(duì)意識(shí)和協(xié)作精神，有較強(qiáng)的溝通能力和書面表達(dá)能力。(8)具有旺盛的精力和學(xué)習(xí)能力，能快速掌握新技術(shù)和新方法。 23第二十三頁，共235頁。第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則(yunz)與模式24第二十四頁，共235頁。2

16、5第二十五頁，共235頁。26第二十六頁，共235頁。用GRASP模式指導(dǎo)(zhdo)設(shè)計(jì)27第二十七頁，共235頁。28第二十八頁，共235頁。29第二十九頁，共235頁。30第三十頁，共235頁。31第三十一頁，共235頁。32第三十二頁，共235頁。33第三十三頁，共235頁。34第三十四頁，共235頁。35第三十五頁，共235頁。36第三十六頁，共235頁。37第三十七頁，共235頁。38第三十八頁，共235頁。39第三十九頁，共235頁。40第四十頁，共235頁。41第四十一頁，共235頁。42第四十二頁，共235頁。43第四十三頁，共235頁。44第四十四頁，共235頁。45第四十

17、五頁，共235頁。46第四十六頁，共235頁。領(lǐng)域(ln y)模型47第四十七頁，共235頁。層次結(jié)構(gòu)領(lǐng)域模型(mxng)從EJB到輕量級(jí)框架48第四十八頁，共235頁。層次結(jié)構(gòu) 表現(xiàn)層（present） 業(yè)務(wù)層 業(yè)務(wù)層外觀 業(yè)務(wù)層核心 領(lǐng)域?qū)ο蠊芾?服務(wù)(fw)/倉庫層 領(lǐng)域?qū)ο髮?持久層 數(shù)據(jù)訪問層 數(shù)據(jù)庫49第四十九頁，共235頁。領(lǐng)域模型中的各種角色：實(shí)體-有唯一的標(biāo)識(shí),并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設(shè)計(jì)時(shí)，實(shí)體的形為最難決斷。為確定行為，我們必須識(shí)別它們的責(zé)任和協(xié)作。類的責(zé)任是指該類要做、知道、或決定的一切，由一個(gè)或多個(gè)方法完成。類中有屬性

18、和關(guān)聯(lián)，協(xié)作就是為完成自己的責(zé)任所調(diào)用其它關(guān)聯(lián)類。值對(duì)象-沒有標(biāo)識(shí)沒有行為。如Address類。工廠-定義創(chuàng)建實(shí)體的方法，封裝實(shí)例化對(duì)象并將一些關(guān)聯(lián)對(duì)象注入。倉庫(repository)管理實(shí)體的集合,主要有查找和刪除實(shí)體的方法.實(shí)現(xiàn)類可以(ky)調(diào)用執(zhí)久化層(如Hibernate，Ibatis)服務(wù)(Service) ，實(shí)現(xiàn)整個(gè)應(yīng)用程序的工作流(workflow)。服務(wù)包含那些無法指派的單個(gè)實(shí)體的行為，由作用于多個(gè)對(duì)象方法組成。如可以(ky)調(diào)用repository查找到實(shí)體對(duì)象，然后委派給這些對(duì)象。服務(wù)和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務(wù)。2）收集返回給表現(xiàn)層的數(shù)據(jù)

19、。3）脫鉤對(duì)象。4）其它事情。服務(wù)可以(ky)說是業(yè)務(wù)的協(xié)調(diào)者，業(yè)務(wù)邏輯可以(ky)分散到實(shí)體對(duì)象中。50第五十頁，共235頁。領(lǐng)域(ln y)模型失血(shxu)模型貧血模型充血模型脹血模型51第五十一頁，共235頁。失血(shxu)模型DO只有屬性及其getter/setter方法，沒有任何(rnh)業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護(hù)與理解困難。52第五十二頁，共235頁。貧血(pnxu)模型DO包含不依賴于持久化的領(lǐng)域(ln y)邏輯；依賴持久化的領(lǐng)域(ln y)邏輯歸入Service層。Service(業(yè)務(wù)邏輯，事務(wù)封裝) DAODO優(yōu)點(diǎn)：各層單向依賴，結(jié)構(gòu)清楚，易于實(shí)現(xiàn)

20、和維護(hù)。設(shè)計(jì)簡單易行，底層模型非常穩(wěn)定。缺點(diǎn)：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過重。53第五十三頁，共235頁。充血(chngxu)模型與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)(shw)和少量邏輯，不和DAO層打交道。Service(事務(wù)(shw)封裝)DO DAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。54第五十四頁，共235頁。缺點(diǎn)：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒有確定的規(guī)則，取決與

21、設(shè)計(jì)人員自己的理解。Service層封裝事務(wù)，須對(duì)所有的DO邏輯提供相應(yīng)的事務(wù)封裝方法，造成重定義所有的Domain logic。Service的事務(wù)化封裝的意義(yy)等于把OO的Domain logic轉(zhuǎn)換為過程的Service 事務(wù)腳本。充血模型在domain層實(shí)現(xiàn)的OO在Service層又變成了面向過程。 55第五十五頁，共235頁。脹血模型(mxng)取消Service層，只剩下DO和DAO層，在DO的domain logic上面封裝事務(wù)。DO(事務(wù)封裝，業(yè)務(wù)邏輯)DAO(RoR甚至合并為一層） 優(yōu)點(diǎn)(yudin)：分層簡化符合OO缺點(diǎn)：service邏輯也強(qiáng)行放入DO ，引起了DO

22、不穩(wěn)定。DO暴露給web層過多的信息，可能引起不必要的耦合。56第五十六頁，共235頁。 原則： 業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯(lu j)，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯(lu j)。 57第五十七頁，共235頁。EJB到輕量級(jí)框架(kun ji) EJB POJO （業(yè)務(wù)邏輯(lu j)） + 輕量級(jí)框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）58第五十八頁，共235頁。EJBEJB：編寫(binxi)分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。提供大量服務(wù)：聲明型事務(wù), EIB容器自動(dòng)啟動(dòng)、提交和回滾事務(wù)。業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶發(fā)起的分布式

23、事務(wù)。提供聲明型安全，大部分情況下不再搖要編寫(binxi)安全代碼求（bean部署描述符里的條目指定準(zhǔn)可以防問某個(gè)具體bean）。59第五十九頁，共235頁。例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬(zhun zhn)的服務(wù)。60第六十頁，共235頁。POJO（業(yè)務(wù)邏輯） +Hiibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）。 典型的EJB方法 POJO方法 組織 過程式業(yè)務(wù)邏輯 面向?qū)ο笤O(shè)計(jì) 實(shí)現(xiàn) 基于EJB POJO 數(shù)據(jù)庫訪問 JDBC/SQL或?qū)嶓wbean 持久層框架 返回給表示層的數(shù)據(jù)DTO 業(yè)務(wù)對(duì)象 事務(wù)管理 EJB容器管理的事務(wù) Spring框架 應(yīng)用程序組裝

24、(z zhun) 顯式的JNDI查詢 依賴注入 61第六十一頁，共235頁。新設(shè)計(jì)是面向?qū)ο蟆⒒赑OJO, 而非基于EJB的過程式。它使用構(gòu)建在JDBC上的持久層框架來訪問數(shù)據(jù)庫, 并不直接使用JDBC。業(yè)務(wù)邏輯由POJO facade而非會(huì)話bean進(jìn)行封裝。事務(wù)由Spring框架而非EJB容器進(jìn)行管理。業(yè)務(wù)邏輯向表現(xiàn)層返回實(shí)際的業(yè)務(wù)對(duì)象,而不是DTO。應(yīng)用程序通過將組件的依賴作為(zuwi)setter或構(gòu)造子參數(shù)傳入來進(jìn)行組裝,而不是之前采用Java命名和目錄接口(JNDI )查詢的組件。由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前看到的EJB版本對(duì)開發(fā)人員要友好。62第六十二

25、頁，共235頁?；谳p量級(jí)框架設(shè)計(jì)的好處是，它提供事務(wù)和持久化時(shí)并不要求應(yīng)用程序類實(shí)現(xiàn)任何特殊接口。甚至當(dāng)應(yīng)用程序的類需要(xyo)運(yùn)行在事務(wù)里或是持久的時(shí)候，它們?nèi)允荘OJO，設(shè)計(jì)者可以繼續(xù)享受POJO的種種好處。63第六十三頁，共235頁。64第六十四頁，共235頁。面向?qū)ο蟮膬?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無所不能的大型類, 而是由大量小類組成, 每個(gè)類只共有若干職責(zé)。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實(shí)世界的概念對(duì)應(yīng), 因此易于理解。其次(qc),面向?qū)ο笤O(shè)汁也更易測(cè)試: 所有類都能并且應(yīng)當(dāng)進(jìn)行獨(dú)立的測(cè)試。E

26、JB只能通過調(diào)用它的public 方法如Transter進(jìn)行測(cè)試,難度大。(只能測(cè)試p-blic方法暴露的復(fù)雜功能,無法測(cè)試其中簡單的部分）。面向?qū)ο笙笤O(shè)計(jì)更易擴(kuò)展, 它可使用設(shè)計(jì)模式，如Stategy和Template等。EJB風(fēng)格的過程式設(shè)計(jì)往往需耍修改核心代碼。65第六十五頁，共235頁。 不適合用面向?qū)ο蟮膱?chǎng)合： 大量數(shù)據(jù)集合的關(guān)系操作。 以數(shù)據(jù)庫為中心的管理程序 ：這個(gè)領(lǐng)域所對(duì)應(yīng)的現(xiàn)實(shí)世界是一個(gè)(y )面向關(guān)系的世界，表與表的關(guān)聯(lián)體現(xiàn)的是彼此的業(yè)務(wù)關(guān)系。 復(fù)雜的SQL固然不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護(hù)也更困難，同時(shí)還損失了效率

27、。 比較大的事務(wù)。 性能要求高的地方。（直接用Sql或者存儲(chǔ)過程；犧牲可維護(hù)性和可復(fù)用性） 上層流程。66第六十六頁，共235頁。 消除(xioch)DTO67第六十七頁，共235頁。部署(b sh)POJO程序68第六十八頁，共235頁。69第六十九頁，共235頁。70第七十頁，共235頁。面向?qū)ο笤O(shè)計(jì)的基本(jbn)原則71第七十一頁，共235頁。72第七十二頁，共235頁。liskov替換(t hun)原則（LSP）73第七十三頁，共235頁。子類型必須能夠(nnggu)替換掉其基類型問題的根源是關(guān)于行為的：基類中有的行為在子類中不存在或不適當(dāng)。IS A的本質(zhì)是指行為的一致，而不是生活中

28、的語言。違反了LSP原則的本質(zhì)是派生類的行為與基類中的不一致。如果違反了LSP原則，常會(huì)導(dǎo)致在運(yùn)行時(shí)的類型判斷(RTTI)違反OCP原則。例如：函數(shù)(hnsh)A的參數(shù)是基類型，調(diào)用時(shí)傳遞的對(duì)象是子類型，正常情況下，增加子類型都不會(huì)影響到函數(shù)(hnsh)A的，如果違反了LSP，則函數(shù)(hnsh)A必須小心的判斷傳進(jìn)來的具體類型，否則就會(huì)出錯(cuò)，這就已經(jīng)違反了OCP原則。74第七十四頁，共235頁。違反LSP導(dǎo)致違反OCP的簡單(jindn)例子75第七十五頁，共235頁。改善(gishn)76第七十六頁，共235頁。例：會(huì)議(huy)管理系統(tǒng)77第七十七頁，共235頁。例：GUI對(duì)象(duxin

29、g)假定假定(jidng)一個(gè)一個(gè)Component代表一個(gè)代表一個(gè)GUI對(duì)象，如按鈕或者文本框等。對(duì)象，如按鈕或者文本框等。78第七十八頁，共235頁。79第七十九頁，共235頁。80第八十頁，共235頁。改善(gishn)281第八十一頁，共235頁。例82第八十二頁，共235頁。接口隔離原則(yunz)（ISP）康凱83第八十三頁，共235頁。例84第八十四頁，共235頁。使用(shyng)委托分離接口85第八十五頁，共235頁。使用(shyng)多重繼承分離接口86第八十六頁，共235頁。內(nèi)接口(ji ku)與外接口(ji ku)87第八十七頁，共235頁。普通(ptng)接口與智能接

30、口88第八十八頁，共235頁。軟件系統(tǒng)壞死(hui s)的癥狀89第八十九頁，共235頁。“Copy”程序程序(chngx)一個(gè)從鍵盤讀入字符一個(gè)從鍵盤讀入字符(z f)并輸出到打印機(jī)的程序。并輸出到打印機(jī)的程序。void Copy()int c;while (c = RdKbd() != EOF)WrtPtr(c);90第九十頁，共235頁。需求(xqi)在變化用戶希望用戶希望(xwng)Copy程序能從紙帶讀入機(jī)中讀入信息。程序能從紙帶讀入機(jī)中讀入信息?，F(xiàn)實(shí)中的約束不能改變接口現(xiàn)實(shí)中的約束不能改變接口Copy程序的第一次修改結(jié)果程序的第一次修改結(jié)果bool ptFlag = false;/

31、remember to reset this flagvoid Copy()int c;while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF)WrtPtr(c);91第九十一頁，共235頁。需求(xqi)在變化2客戶希望客戶希望Copy程序有時(shí)可以輸出到紙帶穿孔機(jī)上。程序有時(shí)可以輸出到紙帶穿孔機(jī)上。/Copy程序的第二次修改程序的第二次修改(xigi)結(jié)果結(jié)果bool ptFlag = false;bool punchFlag = false;/remember to reset these flagvoid Copy()int c;while (c = (

32、ptFlag ? Rdpt() : Rdkbd() != EOF)punchFlag ? WrtPunch(c) : WrtPtr(c);92第九十二頁，共235頁。依賴倒置(dozh)原則（DIP）康凱93第九十三頁，共235頁。相關(guān)(xinggun)概念關(guān)于解耦依賴倒置（DIP）控制反轉(zhuǎn)（IoC）依賴注入（DI）服務(wù)(fw)定位器（SL）有些是手段，有些是原則，不過其間的差異并不太重要，更重要的是其共同點(diǎn)：其根本目標(biāo)都是解除依賴，將組件的配置與使用分離開。其它名詞服務(wù)(fw)組件框架類庫應(yīng)用程序94第九十四頁，共235頁。接口接口(ji ku)和實(shí)現(xiàn)分離和實(shí)現(xiàn)分離 面向(min xin)過

33、程的接口與實(shí)現(xiàn)分離95第九十五頁，共235頁。96第九十六頁，共235頁。97第九十七頁，共235頁。98第九十八頁，共235頁。電影清單(qngdn)的例子一個(gè)組件，用于提供一份電影清單(qngdn)，清單(qngdn)上列出的影片都是由一位特定的導(dǎo)演執(zhí)導(dǎo)的。class MovieLister . public Movie moviesDirectedBy(String arg) List allMovies = finder.findAll(); for (Iterator it = allMovies.iterator(); it.hasNext();) Movie movie = (M

34、ovie) it.next(); if (!movie.getDirector().equals(arg) it.remove(); return (Movie) allMovies.toArray(new MovieallMovies.size(); 99第九十九頁，共235頁。其中真正想要考察(koch)的是如何將MovieLister對(duì)象與特定的finder對(duì)象連接起來。要求：我們希望moviesDirectedBy方法完全不依賴于影片的實(shí)際存儲(chǔ)方式。這個(gè)方法只能引用一個(gè)finder對(duì)象，而finder對(duì)象必須知道如何實(shí)現(xiàn)findAll的細(xì)節(jié)。給finder定義一個(gè)接口： public

35、interface MovieFinder List findAll(); 當(dāng)要實(shí)際尋找影片時(shí)，就必須涉及到MovieFinder 的某個(gè)具體子類。在這里，我把“涉及具體子類”的代碼放在MovieLister 類的構(gòu)造函數(shù)中。100第一百頁，共235頁。對(duì)抗(dukng)變化從一個(gè)逗號(hào)分隔的文本文件(wnjin)中獲得影片列表。class MovieLister. private MovieFinder finder; public MovieLister() finder = new ColonDelimitedMovieFinder(movies1.txt); 對(duì)抗變化：文件(wnjin)

36、清單的名字更改：可以從一個(gè)配置文件(wnjin)獲得文件(wnjin)名。如果用SQL 數(shù)據(jù)庫、XML 文件(wnjin)、web service，或者另一種格式的文本文件(wnjin)來存儲(chǔ)影片清單：用另一個(gè)具體的類來獲取數(shù)據(jù)。該類從MovieFinder接口派生即可。創(chuàng)建合適的MovieFinder派生類的實(shí)例：不能對(duì)抗此變化。101第一百零一頁，共235頁。配置文件設(shè)定配置文件(wnjin)：XML 文件(wnjin)是比較理想的配置方式。movies1.txt102第一百零二頁，共235頁。第三單元：用UML輔助(fzh)系統(tǒng)分析與設(shè)計(jì)103第一百零三頁，共235頁。UML簡介及常見(

37、chn jin)疑難問題辨析 104第一百零四頁，共235頁。UML用來描述模型的內(nèi)容有3種,分別(fnbi)是事物( Things )、關(guān)系Relationships )和圖( Diagrams )。105第一百零五頁，共235頁。UML中的關(guān)系(gun x)UML中的關(guān)系(Relationships )主要包括(boku)4種:1、關(guān)聯(lián)關(guān)系2、依賴( Dependency)關(guān)系3、泛化( Generalization )關(guān)系4、實(shí)現(xiàn)( Realization )關(guān)系106第一百零六頁，共235頁。一些(yxi)常見問題辨析類的層次結(jié)構(gòu)表示屬性與聚合(jh)關(guān)聯(lián)角色關(guān)聯(lián)類107第一百零七頁，

38、共235頁。層次結(jié)構(gòu)108第一百零八頁，共235頁。領(lǐng)域建模重?cái)?shù)(zhn sh)109第一百零九頁，共235頁。細(xì)化類模型(mxng)110第一百一十頁，共235頁。關(guān)聯(lián)(gunlin)角色關(guān)聯(lián)(gunlin)角色名出現(xiàn)在關(guān)聯(lián)(gunlin)終端的旁邊。當(dāng)僅僅使用關(guān)聯(lián)(gunlin)名不足夠表達(dá)清楚后，可以用關(guān)聯(lián)(gunlin)角色名來加強(qiáng)表達(dá)?？梢园衙總€(gè)名稱都當(dāng)成偽屬性，關(guān)聯(lián)(gunlin)角色名提供了一種可以遍歷關(guān)聯(lián)(gunlin)的方法。111第一百一十一頁，共235頁。 在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色(ju s)名，而不是為每個(gè)引用引入一個(gè)獨(dú)立的類。因?yàn)榻巧?ju s)名可以區(qū)分對(duì)

39、象，所以附在一個(gè)類上的關(guān)聯(lián)名必須唯一（可以把角色(ju s)名想象成類的偽屬性）。同樣，角色(ju s)名不應(yīng)該與類的屬性名重復(fù)。112第一百一十二頁，共235頁。關(guān)聯(lián)(gunlin)類正如可以用屬性描述類的對(duì)象一樣，也可以用屬性來描述關(guān)聯(lián)的鏈接，可以把這樣(zhyng)的一組屬性組成關(guān)聯(lián)類。113第一百一十三頁，共235頁。Actor的一些(yxi)注意事項(xiàng)包括人與系統(tǒng)，總是外部的。定義了邊界。Actor是“角色”，不是特定的人或特定的事。要有恰當(dāng)?shù)拿??？梢苑夯皇强捎锌蔁o的東西。另一方面它可以劃分(hu fn)系統(tǒng)與外部實(shí)體的界限，是系統(tǒng)設(shè)計(jì)的起點(diǎn)。114第一百一十四頁，共235頁。用例

40、的一些(yxi)注意事項(xiàng)是需求分析的第一步。用戶首先關(guān)心功能。用例是對(duì)一個(gè)系統(tǒng)或一個(gè)應(yīng)用的一種單一的使用方式所作的描述,是關(guān)于單個(gè)活動(dòng)者在與系統(tǒng)對(duì)話中所執(zhí)行的處理行為的陳述序列。不是事件流。不是需求規(guī)格說明，但反映了主要的功能性需求。識(shí)別用例最好是從分析流開始。每個(gè)用例都是獨(dú)立的。用例名用動(dòng)賓結(jié)構(gòu)描述，不要寫成一個(gè)名詞。用例是分層的，一般而言，高層/中層用例更有實(shí)際意義。不要將不同(b tn)的用例混合在一起。用例與編碼：低層的用例可以輔助編碼，高層的不能。擴(kuò)展用例：基礎(chǔ)用例不必知道擴(kuò)展用例的細(xì)節(jié)，只提供擴(kuò)展點(diǎn)。115第一百一十五頁，共235頁。倉庫(cngk)信息系統(tǒng)的用例圖116第一百一十

41、六頁，共235頁。借鑒(jijin)RUP的UML建模與分析117第一百一十七頁，共235頁。全局(qunj)分析全局分析側(cè)重于定義擬建系統(tǒng)所采用的構(gòu)架以及影響構(gòu)架的要素。全局分析充分利用相似或問題中的經(jīng)驗(yàn)，避免在確定構(gòu)架上浪費(fèi)人力和物力。選用架構(gòu)模式識(shí)別關(guān)鍵抽象：尋找那些無論在問題域或方案領(lǐng)域都具有普遍意義的概念點(diǎn)。標(biāo)識(shí)(biozh)分析機(jī)制：將那些問題領(lǐng)域（應(yīng)用邏輯）沒有直接關(guān)聯(lián)的計(jì)算機(jī)概念及相應(yīng)的復(fù)雜行為表述為支撐分析工作的“占位符”。選定分析局部：針對(duì)擬建系統(tǒng)的整體架構(gòu)，找出那些蘊(yùn)含相對(duì)高風(fēng)險(xiǎn)的局部作為工作內(nèi)容。118第一百一十八頁，共235頁。全局(qunj)分析常見的分析機(jī)制留存分

42、布式處理安全性進(jìn)程間通信消息路由進(jìn)程控制與同步交易事務(wù)管理信息交換信息的冗余(rn y)錯(cuò)誤檢測(cè)、處理和報(bào)告數(shù)據(jù)格式轉(zhuǎn)換119第一百一十九頁，共235頁。局部(jb)分析提取分析(fnx)類轉(zhuǎn)述需求場(chǎng)景整理分析(fnx)類120第一百二十頁，共235頁。局部(jb)分析分析(fnx)類的類型劃分眾多實(shí)踐表明，如果立足于軟件功能需求，擬建系統(tǒng)往往在三個(gè)維度易于發(fā)生變化：一、擬建系統(tǒng)和外部要素之間交互的邊界；第二，擬建系統(tǒng)要記錄和維護(hù)的信息；第三，擬建系統(tǒng)在運(yùn)行中的控制邏輯。通常按照這三個(gè)變化因素的維度，將分析(fnx)類劃分為三種類型：邊界類、控制類、實(shí)體類系統(tǒng)(xtng)邊界Use Case行

43、為協(xié)調(diào)基本信息121第一百二十一頁，共235頁。局部(jb)分析122第一百二十二頁，共235頁。局部(jb)分析123第一百二十三頁，共235頁。局部(jb)分析124第一百二十四頁，共235頁。局部(jb)分析整理分析類分析類是這樣的類：它代表問題域中的簡潔抽象；分析類映射到真實(shí)世界的業(yè)務(wù)概念（并且據(jù)此仔細(xì)命名）。 問題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來的軟件開發(fā)活動(dòng)）需求的域。通常，這是特定的業(yè)務(wù)領(lǐng)域，如在線銷售或者客戶關(guān)系管理。然而，務(wù)必注意，問題域可能根本不是任何(rnh)特定業(yè)務(wù)活動(dòng)，但 是可能產(chǎn)生需要軟件在其上運(yùn)轉(zhuǎn)的一塊物理硬件這是嵌入式系統(tǒng)?；旧希袠I(yè)務(wù)軟件開發(fā)服 務(wù)于某種

44、業(yè)務(wù)需求，自動(dòng)化一個(gè)已有業(yè)務(wù)過程或者開發(fā)具有有意義的軟件組件的新產(chǎn)品。125第一百二十五頁，共235頁。分析(fnx)類的職責(zé)職責(zé)是類和它的客戶之間的契約或者是類對(duì)它的客戶的義務(wù)。本質(zhì)上，職責(zé)是類提供(tgng)給其他類的 服務(wù)。分析類具有直接同類（由它的名稱所表達(dá)）的目的相一致的以及直接同該類正在建模的真實(shí)世 界“事物”相一致的非常內(nèi)聚的職責(zé)集合，這一點(diǎn)是至關(guān)重要的。例如ShoppingBasket示例，你將期 望該類具有如下職責(zé)：向購物籃添加商品；從購物籃刪除商品；顯示購物籃中的商品。 這是內(nèi)聚的職責(zé)集合，一切都是為了維護(hù)客戶選擇的商品集合。它是內(nèi)聚的，因?yàn)樗械穆氊?zé)都朝著相同的目標(biāo)維護(hù)客

45、戶已經(jīng)選擇的商品集合。實(shí)際上，我們能夠把這些職責(zé)概括為非常高級(jí)層 次的職責(zé)“維護(hù)購物籃”。同樣，向 ShoppingBasket 中添加如下職責(zé)：126第一百二十六頁，共235頁。分析(fnx)類的職責(zé)驗(yàn)證(ynzhng)信用卡；接收付款；打印收據(jù)。 但這些職責(zé)似乎同購物籃的目的或直覺語法不匹配。它們不是內(nèi)聚的，顯然應(yīng)該賦予其他什么類 可能是類CreditCardCompany、類Checkout以及類ReceiptPrinter。把職責(zé)適當(dāng)?shù)胤峙浣o分析類 以最大化每個(gè)類中的內(nèi)聚性，是很重要的。最后，良好的類與其他類之間具有最低數(shù)目的耦合。我們以給定類與其他類具有關(guān)系的數(shù)目來度量類間的耦合度。

46、類間職責(zé)的平均分布趨向于產(chǎn)生低耦合度。把控制或職責(zé)局限于單一的類趨向于增 加到該類的耦合度。127第一百二十七頁，共235頁。分析(fnx)類經(jīng)驗(yàn)法則以下是創(chuàng)建形式良好的分析類的一些經(jīng)驗(yàn)法則。每個(gè)類大約35個(gè)職責(zé)典型地，類應(yīng)該保持盡可能簡單，這通常限制類能夠支持的35個(gè)職 責(zé)的數(shù)目。先前ShoppingBasket 的示例是帶有小的和可管理數(shù)目職責(zé)的專注的類的好的示例。不存在獨(dú)立的類好的OO分析和設(shè)計(jì)的精華是，類相互協(xié)作讓用戶受益。同樣，每個(gè)類應(yīng)該 同小部分類協(xié)作以提供所期望的功能。類可以把它們的一些職責(zé)托付給專注于特定功能的其他“輔助”類。當(dāng)心很多非常小的類 有時(shí)很難取得正確的平衡。如果模型

47、看起來具有大量的非常小的類， 每個(gè)類都具有一個(gè)或者兩個(gè)職責(zé)，那么(n me)你應(yīng)該仔細(xì)查看以把一些小的類整合成更大的類。128第一百二十八頁，共235頁。當(dāng)心少數(shù)幾個(gè)非常龐大的類上述的反面是，模型具有很少的類，但每個(gè)類都是具有職責(zé)數(shù) 量（5）的龐大的類。解決問題(wnt)的策略是依次查看這些類，看看是否每個(gè)類都能夠被分解成為 兩個(gè)或者多個(gè)能夠承擔(dān)恰當(dāng)數(shù)目職責(zé)的、更小的類。當(dāng)心“偽類”偽類其實(shí)是一般的過程函數(shù)，它偽裝成類。當(dāng)心萬能類 存在似乎能夠承擔(dān)任何工作的類?？纯疵Q為“system”和“controller”的 類！處理這個(gè)問題(wnt)的策略是看看萬能類的職責(zé)是否能夠分解成內(nèi)聚的子集。如

48、果是，每個(gè)這些 內(nèi)聚職責(zé)集合可能獨(dú)立成類。這些更小的類協(xié)作以實(shí)現(xiàn)由原始萬能類所提供的行為。129第一百二十九頁，共235頁。分析類經(jīng)驗(yàn)(jngyn)法則 避免深度繼承樹設(shè)計(jì)良好的繼承層次的本質(zhì)是繼承層次中每個(gè)抽象層次應(yīng)該(ynggi)具有良好定義 的目的。容易添加很多實(shí)際上不能服務(wù)于任何目的層次。 實(shí)際上，通常的錯(cuò)誤是使用繼承來實(shí) 現(xiàn)一種功能分解，其中每個(gè)抽象層次恰有一個(gè)職責(zé)！ 無論從哪個(gè)方面來講，這都是無意義的，是會(huì)導(dǎo)致復(fù)雜的、難以理解的模型。 在分析中，類代表業(yè)務(wù)事物，而業(yè)務(wù)事物趨向于形成更寬（不超過三層）的繼承層次。 我們把三層或者更多層次的繼承認(rèn)為是“深度”繼承。 130第一百三十頁，

49、共235頁。第四單元(dnyun)：設(shè)計(jì)模式與軟件設(shè)計(jì)思想131第一百三十一頁，共235頁。設(shè)計(jì)模式132第一百三十二頁，共235頁。設(shè)計(jì)模式在實(shí)際開發(fā)(kif)中的運(yùn)用復(fù)用現(xiàn)有的、高質(zhì)量的、針對(duì)常見的重復(fù)出現(xiàn)問題的解決方案。建立(jinl)通用的術(shù)語以改善團(tuán)隊(duì)內(nèi)部的溝通。將思考轉(zhuǎn)移到更高的視角。判斷是否擁有正確的設(shè)計(jì)，而不僅僅使一個(gè)可以運(yùn)行的設(shè)計(jì)。改善代碼的可修改性。發(fā)現(xiàn)“龐大的繼承體系”的替代方案。133第一百三十三頁，共235頁。GoF中的模式(msh)分類134第一百三十四頁，共235頁。設(shè)計(jì)模式的特點(diǎn)(tdin)設(shè)計(jì)模式最根本的意圖是適應(yīng)需求變化隔離變化的部分與不變的部分，將之封裝起

50、來。針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程達(dá)成高內(nèi)聚合低耦合，提高復(fù)用提倡優(yōu)先使用聚合，而不是(b shi)繼承135第一百三十五頁，共235頁。例一個(gè)日志記錄工具。目前(mqin)需要提供一個(gè)日志API，提供客戶方便地調(diào)用。該日志要求被記錄到指定的文本文件中，記錄的內(nèi)容屬于字符串類型，其值由客戶提供?？梢匀菀椎囟x一個(gè)日志對(duì)象。public class Logpublic void Write(string target, string log) /實(shí)現(xiàn)內(nèi)容; 當(dāng)客戶需要調(diào)用日志的功能時(shí)，可以創(chuàng)建日志對(duì)象，完成日志的記錄：Log log = new Log();log.Write(“error.l

51、og”, “l(fā)og”);136第一百三十六頁，共235頁。137第一百三十七頁，共235頁。138第一百三十八頁，共235頁。例我們需要(xyo)設(shè)計(jì)一個(gè)數(shù)據(jù)庫組件，它能夠訪問Sql Server數(shù)據(jù)庫。如果用ADO.Net，需要(xyo)使用如下的對(duì)象：SqlConnection, SqlCommand, SqlDataAdapter等。不用模式的做法：可以直接創(chuàng)建這些對(duì)象：SqlConnection connection = new SqlConnection(strConnection);SqlCommand command = new SqlCommand(connection);Sq

52、lDataAdapter adapter = new SqlDataAdapter();139第一百三十九頁，共235頁。Connection對(duì)象(duxing)：140第一百四十頁，共235頁。141第一百四十一頁，共235頁。策略(cl)（Strategy）模式142第一百四十二頁，共235頁。練習(xí)(linx)下面是一堆雜亂的類與接口：動(dòng)作冒險(xiǎn)游戲。包括代表游戲角色的類，以及武器行為的類。每個(gè)角色一次只能使用一個(gè)武器，但是可以在游戲的過程中換武器。任務(wù)：1.安排(npi)類。2.找出一個(gè)抽象類、一個(gè)接口、以及八個(gè)類。3.在類之間畫箭頭。 A.繼承。B.實(shí)現(xiàn)接口。C.有一個(gè)關(guān)系。4. 把se

53、tWeapon() 方法放到正確的類中。143第一百四十三頁，共235頁。原始(yunsh)的類與接口144第一百四十四頁，共235頁。例：電子零售(ln shu)系統(tǒng)該電子零售系統(tǒng)必須處理來自不同國家的銷售定單。例如在美國(mi u)與加拿大。需求如下：請(qǐng)況請(qǐng)況過程過程美國l 據(jù)UPS的價(jià)格計(jì)算運(yùn)費(fèi)l 使用美國郵政規(guī)則檢查地址l 根據(jù)銷售額或服務(wù),按照當(dāng)?shù)囟愂找?guī)則計(jì)算稅費(fèi)金額l 使用美元處理款項(xiàng)加拿大l 根據(jù)主要的加拿大托運(yùn)公司的價(jià)格計(jì)算運(yùn)費(fèi)l 使用加拿大郵政規(guī)則檢查地址l 根據(jù)銷售額或服務(wù),按照加拿大各省的稅收規(guī)則計(jì)算稅費(fèi)金額(GST和PST) l 使用加拿大元處理款項(xiàng)145第一百四十五頁

54、，共235頁。分析(fnx)矩陣146第一百四十六頁，共235頁。橋接(qio ji)（Bridge）模式147第一百四十七頁，共235頁。意圖“將抽象部分與它的實(shí)現(xiàn)部分分離(fnl)，使它們都可以獨(dú)立地變化”。抽象部分是指“不同的事物在概念層次上的聯(lián)系”。分離(fnl)是指“讓各部分的行為各自獨(dú)立，或至少顯式指出關(guān)聯(lián)”。148第一百四十八頁，共235頁。例通過引入一個(gè)Rectangle抽象類，利用了這一事實(shí)：不同的Rectangle派生類之間唯一的差異是如何實(shí)現(xiàn)(shxin)drawLine方法。V1Rectangle類的實(shí)現(xiàn)(shxin)方式是：保存一個(gè)DP1對(duì)象的引用，使用DP1對(duì)象的d

55、raw_a_line方法。V2Rectangle類的實(shí)現(xiàn)(shxin)方法是：保存一個(gè)DP2對(duì)象的引用，使用這個(gè)對(duì)象的drawline方法。149第一百四十九頁，共235頁。需求(xqi)變化 用戶要求(yoqi)支持另一種形狀圓形。150第一百五十頁，共235頁。識(shí)別(shbi)變化首先識(shí)別出“什么在發(fā)生變化(binhu)”。在上述的例子中，變化(binhu)點(diǎn)是“不同類型的形狀”和“不同類型的畫圖程序”。共同的“概念”則是“形狀”和“畫圖程序”。 用Shape類來封裝擁有的形狀的概念。形狀有責(zé)任知道如何畫自己。Drawing對(duì)象負(fù)責(zé)畫線和圓。151第一百五十一頁，共235頁。描述(mio

56、sh)變化下一步是描述出現(xiàn)的特定變化：Shape類擁有矩形和圓形。畫圖(hu t)程序分別擁有一個(gè)基于DP1的對(duì)象（V1Drawing）和一個(gè)基于DP2的對(duì)象（V2Drawing）。152第一百五十二頁，共235頁。橋接(qio ji)模式153第一百五十三頁，共235頁。觀察者（observer）模式(msh)康凱154第一百五十四頁，共235頁。155第一百五十五頁，共235頁。命令(mng lng)（command）模式康凱156第一百五十六頁，共235頁。意圖將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤消的操作。別名動(dòng)作(Ac

57、tion)，事務(wù)(Transaction)動(dòng)機(jī)有時(shí)必須向某對(duì)象提交請(qǐng)求，但并不知道關(guān)于被請(qǐng)求的操作或請(qǐng)求的接受者的任何(rnh)信息。例如，用戶界面工具箱包括按鈕和菜單這樣的對(duì)象，它們執(zhí)行請(qǐng)求響應(yīng)用戶輸入。但工具箱不能顯式的在按鈕或菜單中實(shí)現(xiàn)該請(qǐng)求，因?yàn)橹挥惺褂霉ぞ呦涞膽?yīng)用知道該由哪個(gè)對(duì)象做哪個(gè)操作。而工具箱的設(shè)計(jì)者無法知道請(qǐng)求的接受者或執(zhí)行的操作。命令模式通過將請(qǐng)求本身變成一個(gè)對(duì)象來使工具箱對(duì)象可向未指定的應(yīng)用對(duì)象提出請(qǐng)求。這個(gè)對(duì)象可被存儲(chǔ)并像其他的對(duì)象一樣被傳遞。這一模式的關(guān)鍵是一個(gè)抽象的Command類。157第一百五十七頁，共235頁。例子(l zi)158第一百五十八頁，共235頁。

58、結(jié)構(gòu)(jigu)159第一百五十九頁，共235頁。其它(qt)設(shè)計(jì)模式160第一百六十頁，共235頁。VISITOR模式(msh)該系列中的模式(msh)如下:VISlTOR模式(msh)ACYCLIC VISITOR模式(msh)DECORATOR模式(msh)EXTENSION OBJECT模式(msh)161第一百六十一頁，共235頁。例是一個(gè)常見的問題：例如,有一個(gè)Modem對(duì)象(duxing)的層次結(jié)構(gòu)?；愔杏兴姓{(diào)制解調(diào)器的公共方法。派生類代表不同調(diào)制解調(diào)器類型的驅(qū)動(dòng)程序。162第一百六十二頁，共235頁。問題(wnt)假設(shè)需要向該層次結(jié)構(gòu)中增加一個(gè)新方法confrgureFor

59、Unix。使之可在UNIX下工作。在每個(gè)調(diào)制解調(diào)器派生類中該函數(shù)的實(shí)現(xiàn)都不相同。（假設(shè)每個(gè)不同的調(diào)制解調(diào)器在UNIX中都有自己獨(dú)特的配置方法和行為特征）。問題：直接增加configureForUnix方法其實(shí)回避了一個(gè)問題：對(duì)于Windows如何處理? MacOS? Linux? 必須針對(duì)所使用的每一種新操作系統(tǒng)都要向Modem層次結(jié)構(gòu)中增加一個(gè)新方法? 這種做法是丑陋的：我們永遠(yuǎn)無法封閉Modem接口。每當(dāng)出現(xiàn)一種新操作系統(tǒng)時(shí), 就必須更改該接口并重新部署所有(suyu)的調(diào)制解調(diào)器軟件。163第一百六十三頁，共235頁。VISITOR模式(msh)的結(jié)構(gòu)164第一百六十四頁，共235頁。V

60、ISITOR組合(zh)模式VISTTOR模式的一個(gè)非常常見的應(yīng)用是,遍歷大量的數(shù)據(jù)結(jié)構(gòu)并產(chǎn)生(chnshng)報(bào)表。這使得數(shù)據(jù)結(jié)構(gòu)對(duì)象中不含有任何產(chǎn)生(chnshng)報(bào)表的代碼。如果想增加新報(bào)表,只需增加新的訪問者,而不需要更改數(shù)據(jù)結(jié)構(gòu)中的代碼。這意味著報(bào)表可以被放置在不同的組件中,并且僅被那些需要它們的客戶單獨(dú)使用。165第一百六十五頁，共235頁。例：報(bào)表(bobio)生成器一個(gè)表示材料單的簡單數(shù)據(jù)結(jié)構(gòu)。從該數(shù)據(jù)結(jié)構(gòu)可以生成無數(shù)的報(bào)表。兩個(gè)可以統(tǒng)計(jì)的量：成本；數(shù)量例如可以生成一張一個(gè)組合(zh)件總成本的報(bào)表,或者生成一張列出了一個(gè)組合(zh)件中所有零件的報(bào)表。166第一百六十六頁，