面向對象軟件架構設計

1、面向對象軟件架構設計Mail: Msn: 1第一單元：軟件生命周期與軟件架構介紹2第二單元：技術架構視圖面向對象程序設計原則與模式 59用GRASP模式指導設計62領域模型96面向對象設計的基本原則132第三單元：用UML輔助系統(tǒng)分析與設計177UML簡介及常見疑難問題辨析178借鑒RUP的UML建模與分析213第四單元：設計模式與軟件設計思想267設計模式268常用的軟件架構風格及適用情況分析391SOA 及分層架構設計443第五單元：架構設計實踐456目錄2第一單元：軟件生命周期與軟件架構介紹3IT行業(yè)的人才結構與軟件架構師的定位軟件架構師應掌握的知識體系軟件架構設計的特點、層次、分類軟件

2、架構的主要理論、方向和趨勢軟件工廠，實現軟件開發(fā)的產業(yè)化4系統(tǒng)架構師的職責：一、理解系統(tǒng)的業(yè)務需求，制定系統(tǒng)的整體框架（包括：技術框架和業(yè)務框架）二、對系統(tǒng)框架相關技術和業(yè)務進行培訓，指導開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運行中出現的各種問題。系統(tǒng)架構師的目的：對系統(tǒng)的重用、擴展、安全、性能、伸縮性、簡潔等做系統(tǒng)級的把握。系統(tǒng)架構師能力要求：一、系統(tǒng)架構相關的知識和經驗。二、很強的自學能力、分析能力、解決問題的能力。三、寫作、溝通表達、培訓。軟件架構師的定位5角色軟件架構師Software Architect定義主導系統(tǒng)全局分析設計和實施、負責軟件構架和關鍵技術決策的角色6職責領導與協(xié)調整個項目中

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

4、有經驗，包括徹底地理解項目需求，開展分析設計之類軟件工程活動等。具備領導素質，以在各小組之間推進技術工作，并在項目壓力下做出牢靠的關鍵決策。擁有優(yōu)秀的溝通能力，用以進行說服、鼓勵和指導等活動，并贏得項目成員的信任。8以目標導向和主動的方式來不帶任何感情色彩地關注項目結果，構架師應當是項目背后的技術推動力，而非構想者或夢想家（追求完美）精通構架設計的理論、實踐和工具，并掌握多種參考構架、主要的可重用構架機制和模式。具備系統(tǒng)設計員的所有技能，但涉及面更廣、抽象級別更高。9軟件架構師作為整個軟件系統(tǒng)結構的總設計師，其知識體系、技能和經驗決定了軟件系統(tǒng)的可靠性、安全性、可維護性、可擴展性和可移植性等方

5、面的性能。因此一個優(yōu)秀的軟件架構師必須具備相當豐富的知識、技能和經驗。通過對比軟件架構師和系統(tǒng)分析師在軟件開發(fā)中的職責和角色，不難發(fā)現軟件架構師與系統(tǒng)分析師所必需的知識體系也是不盡相同的，系統(tǒng)分析師的主要職責是在需求分析、開發(fā)管理、運行維護等方面，而軟件架構師的重點工作是在架構與設計這兩個關鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識體系中對系統(tǒng)的構架與設計等方面知識體系的要求就相對低些；而軟件架構師在需求分析、項目管理、運行維護等方面知識的要求也就相對低些。軟件架構師的知識體系10成為一名合格的軟件架構師必須具備的知識信息系統(tǒng)綜合知識體系軟件架構知識體系11MFC，MSF，MOF，RUP，J2E

6、E，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRuby On RailsRupBPELWorkflow EngineLBSOracleCMMIMQ？12思考、思考、再思考深入理解、準確把握建設的業(yè)務需求分析所有可見的問題、障礙、風險充分參考已有的成功方案，降低風險交流、討論、博弈、質疑對構思中的方案不斷提出質疑，避免漏洞廣泛聽取各層面的意見，開拓思路反復質疑、逐步完善已有的設計構思在動手實現之前驗證設計方案的正確性軟件架構師在干

7、什么？13軟件知識最好要有系統(tǒng)開發(fā)全過程經驗。對 IT 建設生命周期各個環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設計、物理設計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護等。深入掌握1-2種主流技術平臺上開發(fā)系統(tǒng)的方法。了解多種應用系統(tǒng)的結構。了解架構設計領域的主要理論、流派、框架。軟件架構師的知識結構14業(yè)務知識深入了解系統(tǒng)建設的業(yè)務需求。了解系統(tǒng)的非功能需求和運行維護需求。了解企業(yè) IT 公共設施、網絡環(huán)境、外部系統(tǒng)。軟件架構師的知識結構15基于框架的思維架構設計的層次（Enterprise， Application， etc）IT 的生命周期（What， Why， Where， How， Wh

8、en， etc）成功經驗以及方法論的指導合理把握技術細節(jié)把握各個層次應有的內容合理忽略不應有的技術細節(jié)軟件架構師的思維方式16風險管理意識采用成功經驗、避免不應有的風險多方位的開放思維多維度、多方向、包容性、避免排他性分析、質疑、抽象、歸納沒有絕對好的架構設計，只有相對優(yōu)秀的方案軟件架構師的思維方式17(1)計算機系統(tǒng)綜合知識：包括計算機組成與體系結構、嵌入式系統(tǒng)和操作系統(tǒng)等方面的知識。(2)系統(tǒng)配置和方法：包括系統(tǒng)配置技術和系統(tǒng)性能等方面的知識。(3)典型系統(tǒng)應用：包括網絡應用、數據庫應用和多媒體系統(tǒng)等方面的知識。(4)系統(tǒng)開發(fā)：包括程序設計語言、軟件開發(fā)方法、需求分析和設計方法、測試評審方

9、法、開發(fā)管理、應用系統(tǒng)構建、系統(tǒng)審計、外部資源使用和基于中間件的開發(fā)等方面的知識。(5)安全性和可靠性技術：包括數據安全與保密、防闖入和防病毒、容錯技術、可靠性模型與分析技術、系統(tǒng)可靠性、安全規(guī)章和保護私有信息規(guī)則等方面的知識。信息系統(tǒng)綜合知識體系18(6)標準化：包括標準化的基礎知識、標準化分級、編碼標準、數據交換標準、軟件工程標準、信息安全標準、基于構件的軟件標準和標準化組織機構等方面的知識。(7)信息化基礎：包括政府信息化與電子政務、企業(yè)信息化與電子商務、信息化的有關的法律和規(guī)定等方面的知識。(8)數學和英語：至少具有大學以上的數學和英語基礎知識。19(1)系統(tǒng)計劃：包括項目的提出和可行

10、性分析、系統(tǒng)方案的制定、評價和改進、新舊系統(tǒng)的分析與比較、現有軟、硬件和數據資源的有效利用等。(2)軟件架構設計：包括軟件架構的概念、軟件架構與設計、架構風格、特定領域的架構風格、基于架構的軟件開發(fā)方法、架構評估、軟件產品線和系統(tǒng)演化等。(3)設計模式：包括設計模式的概念、組成、分類和實現、模式和軟件架構的關系等。(4)系統(tǒng)設計：包括處理流程設計、人機界面設計、文件與存儲設計、數據庫設計、網絡應用系統(tǒng)的設計、系統(tǒng)運行環(huán)境的集成與設計、中間件與應用服務器、性能設計與性能評估等。(5)軟件建模：包括定義問題與歸結模型、結構化系統(tǒng)建模與數據流圖、面向對象系統(tǒng)建模、數據庫建模和逆向工程等。軟件架構知識

11、體系20(6)分布式系統(tǒng)設計：包括分布式通信協(xié)議的設計、基于對象與web的分布式設計、基于消息和協(xié)同的分布式設計和異構分布式系統(tǒng)的互操作性設計等。(7)嵌入式系統(tǒng)設計：包括實施任務調度和多任務設計、中斷處理和異常處理、嵌入式系統(tǒng)開發(fā)設計等。(8)系統(tǒng)可靠性分析與設計：包括系統(tǒng)故障模型和可靠性模型、系統(tǒng)的可靠性分析與可靠度計算、提高系統(tǒng)可靠性的措施、系統(tǒng)的故障對策和系統(tǒng)的備份與恢復等。(9)系統(tǒng)的安全性和保密性設計：包括系統(tǒng)的訪問控制技術、數據的完整性、數據與文件的加密、通信的安全和系統(tǒng)的安全設計等。(10)復雜架構設計：包括操作系統(tǒng)的架構、編譯器的架構和大型基礎庫的架構等。21根據軟件架構師的

12、職責和角色定位，以及知識體系，從實踐的角度考慮，合格的軟件架構師應該具有以下能力和經驗：(1)具有8年以上的軟件項目開發(fā)實際工作經驗，其中至少有3年以上的代碼編寫工作經驗，4年以上的基于面向對象和構件開發(fā)方法的軟件產品設計經驗。 (2)具有5個以上大中型開發(fā)項目的總體規(guī)劃、方案設計經驗，有大中型應用系統(tǒng)開發(fā)和實施的成功案例。(3)對相關的技術標準有深刻的認識，對軟件工程標準和規(guī)范有良好的把握。 (4)對.Net或Java技術及整個解決方案有深刻的理解及熟練的應用，精通Web Service，熟練掌握流行的架構。 軟件架構師的任職條件22(5)對設計模式有深刻的理解，并能在此基礎上設計出適合產品

13、特性和質量屬性的框架。(6)具有面向對象的分析、設計和開發(fā)能力，精通UML和XML，能熟練使用Rational Rose、PowerDesigner等工具進行設計。 (7)具有良好的團隊意識和協(xié)作精神，有較強的溝通能力和書面表達能力。(8)具有旺盛的精力和學習能力，能快速掌握新技術和新方法。 23業(yè)務應用層 (Business Application)由應用開發(fā)者開發(fā)應用框架層 (Application Framework)特定領域框架層跨領域框架層基礎框架層 (Foundation Framework)操作系統(tǒng)層架構的分層2425軟件體系結構至少有十幾種思想流派。Zachman框架開放分布式

14、處理領域分析Rational41視圖模型軟件體系結構風格供應商驅動的方案Sun Enterprise JavaBeansMS .Net 體系軟件體系結構2627構件可以最大程度的進行互操作和重用。對系統(tǒng)和處理方式加以標準化，只是增強軟件可操作性和重用性的一種權宜之計，并不能徹底解決問題。分布式處理：借助計算機網絡將分布在不同地點的構件(對象)組織在一起，進行信息處理。分布式處理中的構件可能由不同的廠商開發(fā)、生產，因而構件之間可能存在不一致的接口；另外，構件之間的通信也可能使用不同的協(xié)議。這種兼容異質成分的分布式處理，稱為開放分布式處理。開放分布式處理（ODP）28ISO/ITUT RMODP定

15、義的抽象層次(視角)：企業(yè)視點(Enterprise Viewpoint)purpose， scope and policies信息視點(Information Viewpoint)semantics of information and information processing計算視點(Computational Viewpoint)functional decomaosition工程視點(Engineering Viewpoint)infrastructure required to support distribution技技術視點(Technology Viewpoint )cho

16、ices of technology for implementationRMODP的元模型體系29是一種支持軟件復用的系統(tǒng)的管理過程。將項目專有需求轉化為一般的領域需求。通用功能被用來做水平框架和可復用軟件體系結構的基礎。領域分析30MVC風格管道過濾器風格客戶服務器風格層次系統(tǒng)倉儲（數據庫和黑板）風格面向對象風格基于消息廣播且面向圖形用戶界面的Chiron2風格基于事件的隱式調用風格軟件體系結構風格31調研已有的成功參考架構和相關模式提出系統(tǒng)邏輯架構，包括分層的整體邏輯架構、子系統(tǒng)/模塊組成以及邊界劃分根據。討論邏輯架構的依據、優(yōu)缺點、以及已經考慮和參考的其它方案。設計相關子架構，包括：數

17、據架構、子系統(tǒng)架構、安全架構、網絡架構等。驗證架構設計、確認能夠滿足業(yè)務需求和其他關鍵指標，如性能要求、費用限制等。軟件架構設計過程舉例32處于軟件系統(tǒng)建設的上游需要全面考慮多方面的因素對于同一個問題，可以有多種設計結果是在各種制約條件下取得的較好折衷方案科學 + 經驗 + 藝術“系統(tǒng)架構”往往被濫用軟件架構設計的一些特點需求分析架構設計系統(tǒng)設計系統(tǒng)開發(fā)測試上線33軟件架構的層次34軟件架構的分類35軟件架構 巨大的知識海洋門檻相對較高、職業(yè)生涯非常長相對獨立于技術的新陳代謝適合于喜歡學習的人不斷學習、增加積累、注重經驗注意學習方法論、框架不斷增加各種系統(tǒng)架構的知識經驗積累非常重要成為軟件架構

18、師的途徑36在與高手和同行合作中提高水平與高手的合作是最佳途徑同行之間的交流也非常有效在每一個項目中進行創(chuàng)新 成為軟件架構師的途徑37RUP與XPAgile與CMMMSF軟件生命周期進程模型38能夠較好地解決：軟件項目復雜性和一致一方面的問題傳統(tǒng)的瀑布式開發(fā)39無法解決：軟件項目可變性和不可視性方面的問題瀑布式開發(fā)推遲了風險的規(guī)避40最早的迭代觸及最重大的風險(例如需求或項目可行性風險)。每次迭代產出一個可執(zhí)行(可以通過測試等較客觀的途徑加以驗證)的交付，是系統(tǒng)的一個增量。每次迭代都包含集成與測試。將瀑布開發(fā)迭代地應用于系統(tǒng)增量41迭代式開發(fā)促進風險規(guī)避42嚴重的風險在(項目)大規(guī)模投入之前被

19、解決初期的迭代能獲取更早的用戶反饋測試與集成是連續(xù)的(增量式)客觀(可驗證)的里程碑提供了短期的焦點進度的度量直接依靠對實施成果的評估(而非主觀的估計)部分的實現可以被先行部署迭代式開發(fā)的特點43在RUP先啟階段的迭代中，項目組必須解決開發(fā)目標與范圍、以及技術和商業(yè)可行性的根本風險值不值得做，能不能做。而到了精化階段的迭代，項目組關注的焦點則轉到構架風險上可否大量投入去做。進入項目中成本最高的構建階段后，控制成本、進度和開發(fā)質量的風險將成為所有成員的責任準備好交付給用戶了?最后到了遷移階段，項目組將面臨從客戶和用戶方面引入的各種風險(日程安排、需求變更等)客戶是否滿意。迭代：風險驅動的開發(fā)模型

20、44RUP、XP、Agile 都強調迭代開發(fā)的方式 45rational統(tǒng)一開發(fā)過程 rational公司提供的軟件開發(fā)過程方法，RUP告訴你軟件開發(fā)應該做那些事情，分為哪些階段，每件事情應該做到什么程度。RUP基本是一種根據風險大小安排次序的迭代過程，強調在開發(fā)早期找到相對穩(wěn)定的構架，以免后期因為修改構架而增加太多工作量，另外RUP使用use case捕獲需求作為每一次迭代開發(fā)的開始。RUP46極限編程 是一種指導你如何去開發(fā)的思想。XP的核心是盡可能把所有的事情簡化。XP反對在開發(fā)過程中生成太多文檔，不鼓勵過多考慮未來的需求，鼓勵盡可能早期進行盡可能全面的測試，鼓勵周期盡可能小的迭代開發(fā)以

21、便是系統(tǒng)盡可能早的投入使用。另外還注重雙人編程、CRC和重構技術。 XP47XP在很多方面都和我們傳統(tǒng)意義上得軟件工程不同，同時，它也和傳統(tǒng)得管理和項目計劃得方法不同。不采用瀑布式得軟件工程方法，而采用原型法。在軟件設計中，強調簡單性48角色輪換項目的集體負責 保證8小時工作制，避免加班。有充分的培訓、有每個人的提升空間推行淘汰制有效的招聘制度。強有力的后勤保障制度和輕松的企業(yè)文化結對編程49CMM 告訴組織為了系統(tǒng)化地建立、實施和改進軟件開發(fā)過程應該做些什么，但沒有說明如何去做以及采用哪些具體的技術、策略和方法。CMM 是一套通用的過程實踐標準，適用面很廣。實施CMM 要求組織在過程的制度化

22、建設上付出大量努力，通常被認為是重載（heavy-weight）的模型。XP 與CMM 、RUP 的比較 50XP 是一個針對某種特定環(huán)境（需求變化快的小型團隊）的具體過程實施模型和方法論。它其實是一種演進式的原型化方法（evolutionary prototyping），具有溝通高效、設計簡單、反饋迅速等特點，因而是一種輕載（light-weight）、敏捷（agile）的過程方法。 把XP 的實踐方法與CMM 的KPA（關鍵過程域）進行對照?？梢钥闯鯴P部分滿足或大部分滿足了CMM 2-3 級KPA 的要求，而基本上沒有涉及CMM 4-5 級的KPA。這說明XP 的做法基本符合了CMM 的

23、目標和KPA，但還不完備。51總體上看，XP 側重于具體的過程和開發(fā)技術，而CMM 更關注組織和管理上的問題。XP 缺少的一個重要內容是“制度化”，它不含有被CMM 認為是使良好的工程和管理實踐制度化的關鍵基礎設施和管理要件。52RUP（Rational Unified Process）是一個風險驅動的基于UML 和構件式架構的迭代遞增型開發(fā)過程（框架）。RUP 定義了4 個階段（起始、細化、構造、移交）和9 個科目（業(yè)務建模、需求、分析和設計、實現、測試、部署、配置和變更管理、項目管理、環(huán)境）。這些階段對應著關鍵里程碑的劃分，而不同科目的工作流和活動在生命周期的迭代中可以并發(fā)進行，具體執(zhí)行的

24、程度則可以調節(jié)。53RUP 對于角色、流程、工件和活動的要求是靈活的、可配置的，所以它廣泛地適用于各種類型和規(guī)模的項目。RUP 集中體現了6 個軟件開發(fā)的最佳實踐方法：迭代式開發(fā)、需求管理、構件式架構、基于UML 的可視化建模、持續(xù)校驗質量、變更管理。54RUP 是一種以架構為中心的開發(fā)過程，而這正是大、中型項目成功的關鍵。XP 的編碼和設計活動融為一體，弱化了架構的概念，這是它與強調架構設計的RUP 的最大不同。架構的內涵要遠大于一些簡單的隱喻，它要考慮結構、行為、環(huán)境、使用、功能、性能、可靠性、彈性、重用、可理解性、約束和權衡乃至美學等諸多方面的因素。設計架構的目的不是為了完美地表示系統(tǒng)的

25、全部細節(jié)，而是為了消除最主要和最關鍵的架構風險。55RUP 細化階段的主要目的就是構造出一個可運行的架構原型，作為將來添加需求功能的穩(wěn)固基礎。XP 沒有包含業(yè)務建模、部署等概念，反映了它以編程為中心、節(jié)省一切的哲學。 當然兩者也有不少共同點。例如，它們的基礎都是面向對象方法（取代傳統(tǒng)的結構化方法），都重視代碼、文檔的最小化和設計的簡化，采用動態(tài)適應變化的演進式迭代周期（取代傳統(tǒng)的瀑布型生命周期）、需求和測試驅動并鼓勵用戶積極參與等。 56RUP 提供了非常豐富的內容，總體來說是一個重載的過程。通過定制RUP 這個通用的過程框架，去掉項目不必要的工件和中間環(huán)節(jié)，把XP 的做法（比如短小的迭代周期

26、、結對編程、測試優(yōu)先的設計和重構）吸收進來，也可以實現RUP 過程的敏捷和輕量化。Robert Martin甚至從RUP中裁剪出了一個酷似XP 的最小化RUP 過程dxMART01。57XP、RUP 乃至其他工程和管理方法可以統(tǒng)一起來使用，姑且成之為統(tǒng)一軟件過程（Unified Software Process，USP）。例如，一個大項目團隊在起始和細化階段采用RUP 方法完成需求分析和架構設計，在構造和移交階段采用XP 的做法來實現部分子系統(tǒng)或模塊。 “輕載”、“敏捷”是美麗的詞匯，無人會拒之于門外。XP、RUP 的目標是一致的提高團隊效率、開發(fā)出高質量的軟件，而區(qū)別就在于各自的側重點不同，

27、從而導致兩者的適用情況和應用范圍有差異。然而，它們是可以互補的，無論是以架構為中心，還是以代碼為中心，靈活運用的關鍵就在于掌握其中的最佳實踐方法，實施RUP、XP 或者融合了兩者的過程（比如USP）都將有助于組織更好地實現CMM 目標。 總結58 MSF是一套大型系統(tǒng)開發(fā)指南，它描述了如何用組隊模型、過程模型和應用模型來開發(fā)Client/Server結構的應用程序，是在微軟的工具和技術的基礎上建立并開發(fā)分布式企業(yè)系統(tǒng)應用的參考。 MSF59第二單元：技術架構視圖面向對象程序設計原則與模式606162用GRASP模式指導設計636465666768697071727374757677787980

28、81828384858687888990919293949596領域模型97層次結構領域模型從EJB到輕量級框架98表現層（present）業(yè)務層業(yè)務層外觀業(yè)務層核心領域對象管理/服務/倉庫層領域對象層持久層數據訪問層數據庫層次結構99100領域模型中的各種角色：實體-有唯一的標識,并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設計時，實體的形為最難決斷。為確定行為，我們必須識別它們的責任和協(xié)作。類的責任是指該類要做、知道、或決定的一切，由一個或多個方法完成。類中有屬性和關聯(lián)，協(xié)作就是為完成自己的責任所調用其它關聯(lián)類。值對象-沒有標識沒有行為。如Address類。工

29、廠-定義創(chuàng)建實體的方法，封裝實例化對象并將一些關聯(lián)對象注入。倉庫(repository)管理實體的集合,主要有查找和刪除實體的方法.實現類可以調用執(zhí)久化層(如Hibernate，Ibatis)服務(Service) ，實現整個應用程序的工作流(workflow)。服務包含那些無法指派的單個實體的行為，由作用于多個對象方法組成。如可以調用repository查找到實體對象，然后委派給這些對象。服務和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務。2）收集返回給表現層的數據。3）脫鉤對象。4）其它事情。服務可以說是業(yè)務的協(xié)調者，業(yè)務邏輯可以分散到實體對象中。101失血模型貧血模型充血模

30、型脹血模型領域模型102DO只有屬性及其getter/setter方法，沒有任何業(yè)務邏輯。缺點：行為與數據分離，很多情況導致維護與理解困難。失血模型103DO包含不依賴于持久化的領域邏輯；依賴持久化的領域邏輯歸入Service層。Service(業(yè)務邏輯，事務封裝) DAODO優(yōu)點：各層單向依賴，結構清楚，易于實現和維護。設計簡單易行，底層模型非常穩(wěn)定。缺點：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過重。貧血模型104與貧血模型類似，不同處在于如何劃分業(yè)務邏輯：絕大多業(yè)務邏輯都應該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務和少量邏輯，不和D

31、AO層打交道。Service(事務封裝)DO DAO優(yōu)點：符合OOService層很薄，只充當Facade的角色，不和DAO打交道。充血模型105缺點：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒有確定的規(guī)則，取決與設計人員自己的理解。Service層封裝事務，須對所有的DO邏輯提供相應的事務封裝方法，造成重定義所有的Domain logic。Service的事務化封裝的意義等于把OO的Domain logic轉換為過程的Service 事務腳本。充血模型在domain層實現的OO在Service層又變成了面向過程。 106取消Service層，只剩下DO和DAO層

32、，在DO的domain logic上面封裝事務。DO(事務封裝，業(yè)務邏輯)DAO(RoR甚至合并為一層） 優(yōu)點：分層簡化符合OO缺點：service邏輯也強行放入DO ，引起了DO不穩(wěn)定。DO暴露給web層過多的信息，可能引起不必要的耦合。脹血模型107原則：業(yè)務對象封裝了內在的業(yè)務邏輯，而應用服務封裝了外在于業(yè)務對象的業(yè)務邏輯。 108EJBPOJO （業(yè)務邏輯） + 輕量級框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務管理、安全）EJB到輕量級框架109EJB：編寫分布式業(yè)務應用程序的Java標準架構。提供大量服務：聲明型事務, EIB容器自動啟動、提交和回滾

33、事務。業(yè)務邏輯能參與由遠程客戶發(fā)起的分布式事務。提供聲明型安全，大部分情況下不再搖要編寫安全代碼求（bean部署描述符里的條目指定準可以防問某個具體bean）。EJB110例：在兩個賬號間進行轉賬的服務。111TransferServiceEJB調用AccoutDAO獲取兩個賬號,并執(zhí)行必耍的檢查及其他業(yè)務邏輯。例如,它要核實fromAccount仍有足夠余額,不至于透支。然后,TransferServicEJB再次調用AccountDAO將更新后的賬號信息保存到數據庫中。EJB調用TransactionDAO記錄轉賬操作，TransferServiceEJB返回一個TransferResul

34、t,這是個包含AccOuntDTO及其最近執(zhí)行事的DTO。表示層使用它向顧客顯示Web頁面。112優(yōu)點：類的設計和類之間的關系簡單。TransctionService可直接被遠程調用,并能參與到分布式事務中。缺點（過程式設計的缺點）：業(yè)務邏輯的組織右兩種主要方式:過程式或面向對象。過程式方式以函數為單元組織代碼,操作DTO/VO。DTO/VO遍布各處（函數參數、返回值等）數據與操作的關系非常松散。業(yè)務邏輯變得復雜后， TransfeService EJB必須實現新的特性, 其代碼量也會不斷增加。（例如,增加一神的透支政策）就得向TransfeService 添加更多代碼。導致業(yè)務邏輯類易變得龐

35、大不堪。113EJB規(guī)范實際上鼓勵編寫無狀態(tài)、過程式代碼,實現新的行為時, 編寫一個新的會話bean，加入方法，或在現有方法里添加代碼。Session和Message 都很龐大，SessionFacade和Message Facade模式并不能從根本上解決問題。復雜的EJB難以測i式。開發(fā)和測試乏味冗長。關注點缺少分離的現實。迫便開發(fā)人員同時處琛多個問題（業(yè)務邏輯設計、數據庫模型設計、持久化映射等）114可能需要須編寫大量永遠不會被調用的代碼。需要設計DTO/VO對象。一般來源于實體bean，需維護同步；創(chuàng)建DTO是乏味的工作。用EJB2進行J2EE開發(fā)本質上會排斥許多在其它類型的Java開發(fā)

36、中常見的實踐經驗。115EJB3EJB是POJO,需編寫的樣板代(boilerplate code）大幅減少；代碼和應用服務器環(huán)間的耦合度也下降。實體bean意在成為標準Java持久化機制，在J2EE和J2SE環(huán)境都能運行。支持Java 5 annotation,以替代難寫的部署描述符（用于指定事務屬性、安全屬性和對象/關系映射等細節(jié)）。實體bean 支持繼承。為大部分部署信息提供了默認值。實體bean能向表示層反返回數據,無需在編寫DTO。116POJO（業(yè)務邏輯） +Hiibernate、JDO、iBATIS（持久化）、Spring（事務管理、安全）。 典型的EJB方法 POJO方法 組織

37、 過程式業(yè)務邏輯 面向對象設計 實現 基于EJB POJO 數據庫訪問 JDBC/SQL或實體bean 持久層框架 返回給表示層的數據DTO 業(yè)務對象 事務管理 EJB容器管理的事務 Spring框架 應用程序組裝 顯式的JNDI查詢 依賴注入 117新設計是面向對象、基于POJO, 而非基于EJB的過程式。它使用構建在JDBC上的持久層框架來訪問數據庫, 并不直接使用JDBC。業(yè)務邏輯由POJO facade而非會話bean進行封裝。事務由Spring框架而非EJB容器進行管理。業(yè)務邏輯向表現層返回實際的業(yè)務對象,而不是DTO。應用程序通過將組件的依賴作為setter或構造子參數傳入來進行組

38、裝,而不是之前采用Java命名和目錄接口(JNDI )查詢的組件。由于該設計面向對象,并采用上述輕量級技術,因此較之前看到的EJB版本對開發(fā)人員要友好。118基于輕量級框架設計的好處是，它提供事務和持久化時并不要求應用程序類實現任何特殊接口。甚至當應用程序的類需要運行在事務里或是持久的時候，它們仍是POJO，設計者可以繼續(xù)享受POJO的種種好處。119120面向對象的優(yōu)點：整個設計更易理解和維護。它并不是一個無所不能的大型類, 而是由大量小類組成, 每個類只共有若干職責。此外,諸如Account、BankingTransaction和Overdra類都與現實世界的概念對應, 因此易于理解。其次

39、,面向對象設汁也更易測試: 所有類都能并且應當進行獨立的測試。EJB只能通過調用它的public 方法如Transter進行測試,難度大。(只能測試p-blic方法暴露的復雜功能,無法測試其中簡單的部分）。面向對象象設計更易擴展, 它可使用設計模式，如Stategy和Template等。EJB風格的過程式設計往往需耍修改核心代碼。121不適合用面向對象的場合：大量數據集合的關系操作。以數據庫為中心的管理程序 ：這個領域所對應的現實世界是一個面向關系的世界，表與表的關聯(lián)體現的是彼此的業(yè)務關系。 復雜的SQL固然不好維護，但業(yè)務真是復雜到簡單的SQL都難以描述的程度，采用面向對象描述則更加困難，維

40、護也更困難，同時還損失了效率。比較大的事務。性能要求高的地方。（直接用Sql或者存儲過程；犧牲可維護性和可復用性）上層流程。122123封裝對持久層框架的調用：盡管Hibernare和JDO提供了透明持久化,但應用程序的某些部分仍必須調用JDO和Hibernate的APl來保存、查詢和刪除持久對象。例如,必須調用持久層框架獲取賬戶,然后創(chuàng)建BankingTransaction。一種做法是讓TransferService直接i周由持久層框架API。但這樣會將TransferService與持久層框架、數據庫耦合在一起。更好的做法：用接口裝Hibernate或JDO相關代碼。用倉庫封裝持久層框架,

41、 對應用程序其余部分隱藏持久化細節(jié)。124消除DTO125使POJO具有事務性（使用Spring）126部署POJO程序127128129130131實體：有唯一標識的對象值對象：沒有唯一標識的對象工廠：定義創(chuàng)建實體的方法倉庫：管理實體的集合；封裝持久層框架；查找實體；（兼當工廠）服務：實現無法指派給單個類的責任；封裝裝領域模型132133134一般認為：總是先有應用程序對象模型，再有配套的持久化方案。上班以后發(fā)現，現實完全不需要這樣。業(yè)務被化解為神圣的表，實體表，引用表，鏈接表。整個系統(tǒng)非常靈活，所有的程序配置也全部在表里，還有專門的表來記錄表和表之間的join關系和一些預先寫好的sql子句

42、。真是表中有程序，程序在表中。JAVA需要做什么呢？對，拼接SQL。代碼再惡心也沒關系，而且只要面向過程，完全不必擔心有性能問題，要知道應用程序的響應時間是納秒級的，而數據庫的相應時間是毫秒級的。萬一很慢，那肯定只是你SQL沒寫好。什么靈活性更是沒意義，客戶都是外行。反過來講，就算你OO厲害，別人程序一改一周，你的程序半天搞定，也只是給項目經理認為是你的改動本身簡單，別人的復雜。再退一萬步講，就算客戶丟了，那也是客服的事情，銷售或者財務出身的老板完全不會把這些怪罪到你頭上。爭議1135JAVA說完了，回頭看看SQL。數據越來越多，系統(tǒng)越來越慢。起初毫秒級響應的操作，慢慢變成秒級，到了分鐘級客戶

43、就會來抱怨了。這個時候如果你SQL不錯就可以自告奮勇去調優(yōu)，很容易就能發(fā)現很多初級錯誤。簡單改改，再優(yōu)化下索引，效果立竿見影。人們對你贊賞有加，認為這就是技術的力量。136做一個J2EE系統(tǒng)時，一開始必須從中間層Domain Model開始，這就是域模型驅動，而不是被具體技術牽著鼻子走，各個層技術鬧騰得厲害，整合起來時卻很難。所以必須以Domain Model設計為中心，再加入其他輔助對象，與Domain Model建立對象關聯(lián)(通過類圖實現的四種類關系)，而各個技術都是圍繞類圖的類各自完成自己功能。理清這個思路，從中間組件層入手，就能順藤摸瓜，問題迎刃而解，這也是組件層（有些人說是構件）重要

44、的原因，面向組件（面向構件）編程的重要性。實際上，這也是域建模 和框架重要的原因，使用UML依靠usecase設計出類圖、用模式實現類圖、使用框架（表現層 組件層 持久層框架）來進行代碼級別實現，最終完成一個高質量的J2EE系統(tǒng)。137面向對象設計的基本原則138139liskov替換原則（LSP）140問題的根源是關于行為的：基類中有的行為在子類中不存在或不適當。IS A的本質是指行為的一致，而不是生活中的語言。違反了LSP原則的本質是派生類的行為與基類中的不一致。如果違反了LSP原則，常會導致在運行時的類型判斷(RTTI)違反OCP原則。例如：函數A的參數是基類型，調用時傳遞的對象是子類型

45、，正常情況下，增加子類型都不會影響到函數A的，如果違反了LSP，則函數A必須小心的判斷傳進來的具體類型，否則就會出錯，這就已經違反了OCP原則。子類型必須能夠替換掉其基類型141違反LSP導致違反OCP的簡單例子142改善143問題描述用來管理各種各樣的會議參與者信息。數據庫里面有個表Participants，里面的每條記錄表示一個參會者。因為經常會發(fā)生用戶誤刪掉某個參會者的信息。所以用戶刪除時，并不會真的刪除那參會者的信息，而只是將該記錄的刪除標記設為true。24小時以后，系統(tǒng)會自動將這條記錄刪除。但是在這24小時以內，如果用戶改變主意了，系統(tǒng)還可以將這條記錄還原，將刪除標記設置為fals

46、e。 例：會議管理系統(tǒng)144145改善146假定一個Component代表一個GUI對象，如按鈕或者文本框等。例：GUI對象147148149改善2150例151改善：提取公共部分替代繼承152接口隔離原則（ISP）康凱153安全系統(tǒng)，有一些Door對象可以被加鎖和解鎖，并且Door對象知道自己是開著還是關著的。需求變化：實現一個TimedDoor，如果門開著的時間過長，它就會發(fā)出警報聲。為了做到這一點，TimeDoor對象需要和一個Timer的對象交互。如何將TimerClient與TimedDoor類聯(lián)系起來？例154一種方案155Door依賴于TimerClient 并不是所有種類的Do

47、or都需要定時器。違反LSP：不需時鐘的派生類中需要提供TimeOut的退化方法。不必要的復雜和重復性：使用這些派生類的客戶程序被迫包含TimerClient的定義。Door接口被TimeOut方法污染了：持續(xù)的加入方法會使Door接口不斷變胖。每次Door中加入一個方法，其它派生類中都需要對自己不需要的方法提供退化處理?？蛻魧imerClient接口的改變會影響接口使用者。例如需要在Timer中注冊多個超時通知（在TimeOut方法中加入超時ID），則即使不需要定時器的類也會受影響。問題156使用委托分離接口157使用多重繼承分離接口158內接口與外接口159普通接口與智能接口160軟件系

48、統(tǒng)壞死的癥狀161一個從鍵盤讀入字符并輸出到打印機的程序。void Copy()int c;while (c = RdKbd() != EOF)WrtPtr(c);“Copy”程序162用戶希望Copy程序能從紙帶讀入機中讀入信息。現實中的約束不能改變接口Copy程序的第一次修改結果bool ptFlag = false;/remember to reset this flagvoid Copy()int c;while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF)WrtPtr(c);需求在變化163客戶希望Copy程序有時可以輸出到紙帶穿孔機上。/Copy程

49、序的第二次修改結果bool ptFlag = false;bool punchFlag = false;/remember to reset these flagvoid Copy()int c;while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF)punchFlag ? WrtPunch(c) : WrtPtr(c);需求在變化2164初始的設計的問題依賴關系的不靈活性：高層模塊直接依賴于底層細節(jié)。Copy模塊直接依賴于KeyBoardReader和PrinterWriter依賴倒置：可以用Strategy模式實現依賴的倒置。針對實現編程，而沒有針對接口編

50、程。165依賴倒置原則（DIP）康凱166關于解耦依賴倒置（DIP）控制反轉（IoC）依賴注入（DI）服務定位器（SL）有些是手段，有些是原則，不過其間的差異并不太重要，更重要的是其共同點：其根本目標都是解除依賴，將組件的配置與使用分離開。其它名詞服務組件框架類庫應用程序相關概念167面向過程的接口與實現分離接口和實現分離168169170依賴于特定函數的框架171問題：雙向依賴：應用程序依賴GUI框架：應用程序調用GUI框架中的CreateWindow()函數來創(chuàng)建窗口GUI框架依賴應用程序：GUI框架不了解該窗口接收到窗口消息后應該如何處理，這一點只有應用程序最為清楚。因此，當GUI框架需

51、要發(fā)送窗口消息時，又必須調用應用程序定義的某個特定的窗口函數。雙向依賴關系的缺陷：由于GUI框架調用了應用程序中的某個特定函數， GUI框架無法獨立存在，換一個新的應用程序，GUI框架就要做相應的修改。如何消解框架系統(tǒng)對應用程序的依賴關系是實現框架系統(tǒng)的關鍵?？刂品崔D（IoC）172通過回調函數消解框架到運用程序的依賴：173通過模板方式消解GUI框架到應用程序的依賴174175176一個組件，用于提供一份電影清單，清單上列出的影片都是由一位特定的導演執(zhí)導的。class MovieLister . public Movie moviesDirectedBy(String arg) List a

52、llMovies = finder.findAll(); for (Iterator it = allMovies.iterator(); it.hasNext();) Movie movie = (Movie) it.next(); if (!movie.getDirector().equals(arg) it.remove(); return (Movie) allMovies.toArray(new MovieallMovies.size(); 電影清單的例子177其中真正想要考察的是如何將MovieLister對象與特定的finder對象連接起來。要求：我們希望moviesDirect

53、edBy方法完全不依賴于影片的實際存儲方式。這個方法只能引用一個finder對象，而finder對象必須知道如何實現findAll的細節(jié)。給finder定義一個接口： public interface MovieFinder List findAll(); 當要實際尋找影片時，就必須涉及到MovieFinder 的某個具體子類。在這里，我把“涉及具體子類”的代碼放在MovieLister 類的構造函數中。178從一個逗號分隔的文本文件中獲得影片列表。class MovieLister. private MovieFinder finder; public MovieLister() finde

54、r = new ColonDelimitedMovieFinder(movies1.txt); 對抗變化：文件清單的名字更改：可以從一個配置文件獲得文件名。如果用SQL 數據庫、XML 文件、web service，或者另一種格式的文本文件來存儲影片清單：用另一個具體的類來獲取數據。該類從MovieFinder接口派生即可。創(chuàng)建合適的MovieFinder派生類的實例：不能對抗此變化。對抗變化179public void testWithPico() MutablePicoContainer pico = configureContainer(); MovieLister lister = (

55、MovieLister) pico.getComponentInstance(MovieLister.class); Movie movies = lister.moviesDirectedBy(Sergio Leone); assertEquals(Once Upon a Time in the West, movies0.getTitle(); 客戶代碼180為了讓MovieLister 類接受注入，需要為它定義一個設值方法，它接受類型為MovieFinder的參數： class MovieLister. private MovieFinder finder; public void se

56、tFinder(MovieFinder finder) this.finder = finder; 類似地在MovieFinder的實現類中，定義一個設值方法，接受類型為String 的參數： class ColonMovieFinder. public void set(String ) this. = ; Spring 注入181設定配置文件：XML 文件是比較理想的配置方式。movies1.txt配置文件182第三單元：用UML輔助系統(tǒng)分析與設計183UML簡介及常見疑難問題辨析184UML用來描述模型的內容有3種,分別是事物( Things )、關系Relationships )和圖(

57、 Diagrams )。185UML中的事物包括結構事物、行為事物、組織事物和輔助事物(也稱注釋事物)。結構事物( Structure Things )結構事物主要包括7種,分別是類、接口、協(xié)作、用例、活動類、組件和節(jié)點:UML中的事物186行為事物（Behavior Things）行為事物也稱動作事物,是UML模型中的動態(tài)部分,代表時間和空間上的動作。行為事物主要有兩種:交互和狀態(tài)機。它們是UML模型中最基本的兩個動態(tài)事物元素,通常和其他的結構元素、主要的類、對象連接在一起。(1)交互(Interaction)在UML圖中,交互的消息通常畫成帶箭頭的直線。(2)狀態(tài)機( State Mach

58、ine )狀態(tài)機是對象的一個或多個狀態(tài)的集合。1873、組織事物(Grouping Things)組織事物也稱分組事物,是UML模型中組織的部分,可以把它看作一個個的盒子,每個盒子里面的對象關系相對復雜,而盒子與盒子之間的關系相對簡單。組織事物只有一種,稱為包（Package）包是一種有組織地將一系列元素分組的機制。包與組件的最大區(qū)別在于,包純粹是一種概念上的東西,僅僅存在于開發(fā)階段結束之前,而組件是一種物理元素,存在于運行時。在UML圖中,包通常表示為一個類似文件夾的符號。1884、輔助事物(Annotation Things)輔助事物也稱注釋事物,屬于這一類的只有注釋( Annotatio

59、n )。注釋就是UML模型的解釋部分。在UML圖中,一般表示為折起一角的矩形。189UML中的關系(Relationships )主要包括4種:關聯(lián)關系、依賴關系、泛化關系和實現關系。1、關聯(lián)關系是一種結構化的關系,指一種對象和另一種對象有聯(lián)系。給定關聯(lián)的兩個類,可以從其中的一個類的對象訪問到另一個類的相關對象。在UML圖中,關聯(lián)關系用一條實線表示。另外,關聯(lián)可以有方向,表示該關聯(lián)在某方向被使用。只在一個方向上存在的關聯(lián),稱作單向關聯(lián)(Unidirectional Association ),在兩個方向上都存在的關聯(lián),稱作雙向關聯(lián)( Bidirectional Association)。UML

60、中的關系1902、依賴( Dependency)關系對于兩個對象X、Y,如果對象X發(fā)生變化,可能會引起對另一個對象Y的變化,則稱Y依賴于X。在UML圖中,依賴關系用一條帶有箭頭的虛線來表示。3、泛化( Generalization )關系UML中的泛化關系定義了一般元素和特殊元素之間的分類關系,與和C+及Java中的繼承關系有些類似。在UML圖中,泛化關系用一條帶有空心箭頭的實線來表示。1914、實現( Realization )關系實現關系將一種模型元素(如類)與另一種模型元素(如接口)連接起來,其中接口只是行為的說明而不是結構或者實現。真正的實現由前一個模型元素來完成。在UML圖中,實現關