軟件設計期末復習重點

1、愛第一章 軟件工程與軟件設計1.1軟件工程軟件分類：1. 系統(tǒng)軟件2. 實時軟件3 嵌入式軟件4. 科學和工程計算軟件5. 事務處理軟件6. 人工智能軟件7. 個人計算機軟件軟件工程由方法、工具和過程三個要素組成1.3軟件開發(fā)過程模型131瀑布模型：是既自頂向下結構化開發(fā)模型需求說明書甲題定義定義做什么的問題結構 L可行性誚h , 設計如何做的體系結構I>|；：心|維護階段WWn 口| | 修改設計雇諾 |樹報告1.3.2快速原型模型快速原型棋型1.3.3螺旋模型由四部分組成:1. 需求定義2. 風險分析3. 工程實現(xiàn)4. 評審；特點:1. 瀑布模型+快速原型+風險分析2. 迭代過程制定

2、計劃 決定目標. 方案和限制用戶評估析提交線評審實施工程開發(fā)、驗證 下一產(chǎn)品風險分析評價方案、 識別風險、 消除風險需求劃幵發(fā)計劃軟件產(chǎn) 品設計可運行原樂詳細設計單元譚碼f 組裝測試I 亠J驗收打加 實現(xiàn):測試:測貳II1.4軟件設計軟件設計的概念：對軟件如何被開發(fā)出來的一種描述1.5軟件體系結構軟件體系結構的左義（較有影響力的泄義）：1. 軟件體系結構是軟件系統(tǒng)的結構，包括軟件元素，軟件元素外部可見的屬性以及這些軟 件元素之間的關系；2. 軟件體系結構是軟件系統(tǒng)的基本組織，包括構件，構件之間，構件與環(huán)境之間的關系， 以及相關的設計和演化原則。第二章2.1 UML概述2.1.3 UML2.0的

3、建模機制建模機制中包含的13種視圖模型可以劃分為結構視圖和行為視圖兩種類型。建模機制包括：結構建模，行為建模結構建模包含：類圖，包圖，對象圖，構件圖，組合結構圖，部署圖行為建模包含：活動圖，交互圖（順序圖，通信圖，交互概覽圖，時序圖），狀態(tài)圖，用例 圖2.2面向對象開發(fā)方法2.3 UML2.0結構建模2.3.1類圖（作用）：類圖是UML中最基本、也是最重要的一種視圖，它用來刻畫軟件中類 等元素的靜態(tài)機構關系。依賴關系：兩個類之間存在依賴關系,表明一個類使用或需要知道另個類中包含的信息。Customer > Productcatalog關聯(lián)關系：兩個類之間存在關聯(lián)關系，表明這兩個類的實例之

4、間存在語義上的聯(lián)系。Person+Employee+EmployeeCompany*1聚集關系聚集關系表明兩個類的實例之間存在一種擁有或屬于關系，可以看做是一種比較 弱的整體的一部分關系，或是一種邏輯上的隸屬關系。（圖上菱形是空的）Pers on1 tPers on2.4 UML 2.0行為建模2.4.1 順序圖：（給出用例畫出順序圖）【課本41頁】2.4.7 用例圖：（作用，參與者，用例）【課本50頁】作用：用例圖通常被用來描述系統(tǒng)的需求，從用戶的角度對系統(tǒng)的功能視點進行建 模。用例：一個用例代表系統(tǒng)執(zhí)行的一組動作，這些動作完成特左的任務，并產(chǎn)生對用 戶或外部實體可觀察的結果。用例用來描述系

5、統(tǒng)對外可見的需求或功能。參與者：參與者是與用例發(fā)生交互的系統(tǒng)外部角色，必須是被開發(fā)的系統(tǒng)范囤之外 的角色（不必在本開發(fā)系統(tǒng)中實現(xiàn)），它們只與系統(tǒng)發(fā)生某種形式的交互。第三章軟件設計基礎3.1軟件設計的基本概念3丄1抽象與逐步求精（概念）【課本55頁】抽象："抽象"是一個心理學概念，它要求人們將注總力集中在某一層次上考慮問題, 而忽略那些低層次的細節(jié)。是管理、控制復雜性的基本策略。逐步求精："逐步求精"可視為一種早期的自頂向下設汁策略，其主要思想是，針對 某個功能的宏觀描述用逐步求精的方法不斷地分解，逐步確立過程細肖，直至該功 能用程序語言描述的算法實現(xiàn)為止

6、。3.1.2模塊化與信息隱藏（概念、好處）【課本57頁】模塊化：即把軟件劃分為可獨立命名和訪問的部件，每個部件稱為一個模塊，當把所有模塊 組裝到一起時則獲得滿足問題需要的一個解。信息隱藏：即一個模塊的開發(fā)者不必看到其它模塊的內(nèi)部，只需知道其接口即可，這使得每 個模塊的開發(fā)人員所要處理的復雜性顯著降低。未來達到信息隱藏的目的，模板應該被設計 為其所含信息（過程和數(shù)據(jù)）對于那些不必要的信息模塊不可訪問。3.1.3內(nèi)聚與耦合（不同內(nèi)聚概念、判斷、舉例）【課本58頁】1內(nèi)聚偶然性內(nèi)聚：一個模塊內(nèi)各成分為完成一組功能而組合在一起，它們相互之間即使 有關系，也很松散（內(nèi)聚程度最低）例1: 一個程序員寫完一

7、個程序后發(fā)現(xiàn)有一組語句多處岀現(xiàn)，于是為了節(jié)省內(nèi)存便 將這組語句單獨組成一個模塊。例2：工具模塊邏輯性內(nèi)聚：模塊完成的諸任務邏輯上相關時序內(nèi)聚：一個模塊包含的任務必須在同一時間內(nèi)執(zhí)行例：系統(tǒng)的初始化過程性內(nèi)聚：模塊內(nèi)成分彼此相關，并且必須按特立的次序執(zhí)行通信內(nèi)聚；模塊中各成分都將對數(shù)據(jù)結構的同一區(qū)域進行操作 例如：從同一磁帶上讀取不相干的數(shù)據(jù)一一可能破壞獨立性。順序性內(nèi)聚：各成分均與同一功能相關，且處理按序執(zhí)行功能性內(nèi)聚：所有成分形成一個整體，完成單個功能（內(nèi)聚程度最高）2.耦合非直接耦合：兩個模塊中的任一個都不依賴對方能獨立工作。（耦合度最低）例1： A訪問C的內(nèi)部數(shù)據(jù)或不通過正常入口而轉入C

8、的內(nèi)部。例2：部分代碼重疊（常出現(xiàn)在匯編程序中）例3： 個模塊有多個入口（功能）數(shù)據(jù)耦合：兩模塊間通過參數(shù)交換信息，數(shù)據(jù)僅限于數(shù)據(jù)?？刂岂詈希耗K間傳遞的信息含有控制信息。特征耦合：介于數(shù)據(jù)耦合和控制耦合之間。外部耦合：若干模塊均與同一外部環(huán)境關聯(lián)。公共耦合：若T模塊通過全局的數(shù)據(jù)環(huán)境相互作用。內(nèi)容耦合：一個模塊使用列一模塊內(nèi)部的數(shù)據(jù)或控制信息，或一個模塊直接轉移到 另一模塊內(nèi)部。（最高耦合度）3. 3軟件設計的質量1. 結構良好2. 充分性3. 可行性4. 簡單性5. 實用性6. 靈活性7. 健壯性&可移植性9. 可復用性10. 標準化靈活性（如何提高靈活性，可靠性）【課本67頁】舉

9、例：網(wǎng)站成員注冊八 membersO.n O* MemberWebSite register()class WebsiteMembermembers;/ or maybe：vector members; void register(Member aMember) 怎樣才能使設訃更靈活以注冊新類型的成員？解決方案：引入一個基類，將基類抽象化，根據(jù)需要產(chǎn)生繼承類 我們之所以進行靈活的設計，因為變化和重用是經(jīng)常出現(xiàn)的2. 健壯性1. 防止錯誤輸入0用戶輸入0不是用戶的輸入數(shù)據(jù)通信其他應用方法調用2. 防止開發(fā)錯誤錯誤的設計錯誤的實現(xiàn)檢査輸入在繼續(xù)進行處理之前，可以檢査應用程序的所有輸入的方法。檢查類

10、型（例如：整形）；檢查與前置條件和不變式的輸入為提高健壯性而初始化提供靜態(tài)方法，用來為類產(chǎn)生標準的默認值提高健壯性的參數(shù)傳遞技術保證方法正確調用引入一個捕獲參數(shù)的類并將約朿條件合并強化意圖通過防I匕設汁和實現(xiàn)中的錯誤來提髙健壯性強化計劃，按計劃使用相應功能3. 4軟件體系結構設計【課本68頁】“4+1”模型：每一個視圖只關心系統(tǒng)的一個側而，5個視圖結合在一起才能反映系統(tǒng)的軟 件體系結構的全部內(nèi)容。1. 邏輯視圖：主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務。在面向對象技術中， 通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。2. 進程視圖：該視圖捕獲設汁中關于并

11、發(fā)和同步的內(nèi)容，重視一些非功能性需求。3. 開發(fā)視圖：該視圖主要描述軟件在開發(fā)環(huán)境中的靜態(tài)結構，該視圖的構建和連接件分別映 射到子系統(tǒng)或模塊，關注于在軟件開發(fā)環(huán)境中軟件模塊的組織。軟件可以被打包為子系統(tǒng), 并按層次進行組織。4. 物理視圖：該視圖描述軟件到硬件的映射關系，反應了軟件的分布特征。把不同的軟件元 素，例如進程和任務等，映射到不同的物理節(jié)點上，并關注物理環(huán)境的拓撲結構以及節(jié)點間 的通信。5. 場景：場景通常是最重要的需求，一方而作為設汁中發(fā)現(xiàn)體系結構元素的驅動器，列一方 而在設計完成后，充當確認和驗證的證據(jù)。開發(fā)人員 軟件管理集成人員 性能可擴展性最終用戶 功能特性邏輯視圖開發(fā)視圖/

12、f J 場最/' 1.進程視圖物理視圖系統(tǒng)工程師拓撲通借3.5髙可信軟件設計在等待外部信號的程序段中，不允許無限制地等待。正確的做法應是，或采用循環(huán)等待 次數(shù)控制，或使用定時器，使得規(guī)定時間內(nèi)（無論成功或失?。┍仨毐ＷC退出等待外部信 號的程序段。A寫flag可能寫不上不允許的設計方法建議釆用的設計方法B負正左讀出flagB扌可能寫不上vKite data/ 、%read date/ 1vmte 1 to flag/T、B正左邃出flagB?write 0 to flag握手標志置寫不上的可能read out flagwiitBdataBwrite 1 toftagreM out fla

13、g可靠的設計方法3. 5. 2容錯設計 1避錯：避錯設計是使軟件產(chǎn)品在設計過程中，不發(fā)生錯誤或少發(fā)生錯誤的一種設 計方法。避錯的設計原則是控制和減少程序的復雜性。從開發(fā)方法、工具等多處著手避免需求錯誤深入研究用戶的需求(用戶申明的和未申明的)用戶早期介入，如采用原型技術選擇好的開發(fā)方法結構化方法：包括分析、設計、實現(xiàn)面向對象的方法：包括分析、設計、實現(xiàn) 基于部件的開發(fā)方法(COMPONENT BASED)快速原型法 2.査錯：軟件査錯設計是指在設計中賦予程序某些特殊的功能，使程序在運行中自 動査找存在錯誤的一種設計方法。被動式錯誤檢測在程序的若干部位設置檢測點，等待錯誤征兆的岀現(xiàn)主動式錯誤檢測

14、對程序狀態(tài)主動進行檢査檢測原則相互懷疑原則：在設計任何一個單元、模塊時，假設其它單元、模塊存在著 錯誤;立即檢測原則：當錯誤征兆出現(xiàn)后，要盡快查明，以限制錯誤的損害并降低 排錯的難度。負效應所設巻的“接收判據(jù)”不可能與預期的正確結果完全吻合，導致錯判或漏 判；軟件增加了冗余可能降低可靠性 3改錯：改錯設計是指在設汁中，賦予程序自我改正錯誤、減少錯誤危害程度的能 力的一種設計方法。改正錯誤的前提是已經(jīng)準確地找出軟件錯誤的起因和部位(故障檢測與故障左位合 稱故障診斷)，程序又有能力修改、剔除有錯誤的語句?，F(xiàn)階段僅限于減少軟件錯誤造成的有害影響，或將有害影響限制在一個較小的范用。 常采用故障隔離技術

15、。第四章4. 2用例分析與設計4.2.3用例設計描述【課本105頁】案例：銀行ATM自動柜員機的需求簡述(本案例將要開發(fā)的ATM系統(tǒng)能夠為顧客提 供以下基本服務，它們統(tǒng)一稱為交易)：取款服務。顧客可以用銀行卡從對應的賬戶中支取現(xiàn)金，現(xiàn)金必須是100元 的整數(shù)倍，且每次取款不能超過2000元。存款服務。顧客可以把現(xiàn)金存入與銀行卡對應的賬戶中。轉帳服務。顧客可以把一個銀行卡對應的賬戶中的款項轉帳到另一個銀行賬 戶中。査詢服務。顧客能夠查詢一個銀行卡對應的賬戶中的余額。 該ATM系統(tǒng)包括以下組成部分：讀卡器交互的控制臺，鍵盤及顯示器送出現(xiàn)金的裝巻，取款器存款的插槽，存款器打印機啟動和關閉ATM系統(tǒng)的

16、開關鍵盤 ATM系統(tǒng)與銀行服務通過特圧的網(wǎng)絡連接進行通信 ATM系統(tǒng)在提供以上服務的過程中，必須滿足以下要求 一個顧客可以在最終確認前放棄一項交易 ATM在執(zhí)行交易過程中將與銀行系統(tǒng)進行通信，對是否允許交易進行驗證 ATM為每次成功的交易提供一個打印回執(zhí) ATM需要維護一個內(nèi)部日志，對每次交易進行記錄參與者：與系統(tǒng)交互的人、設備、其他系統(tǒng)"顧客"(Customer) “操作管理人員”(Operator) “銀行服務器” (Bank System) "讀卡器"(Card Reader) "存款器"(Cash Acceptor) &quo

17、t;取款器” (Cash Dispenser) “打印機” (Printer)用例描述：用例夕I稱:Withdrawal 參與者:Customer. Bank System. Card Reader, Cash Dispenser, Printer前置條件:顧客已插入銀行卡，密碼驗證正確，顧客按下“取款”按鈕主事件流:()顧客輸入取款金額，并確認。系統(tǒng)認可取款金額，并發(fā)送指令給取款器。取款器把相應金額的現(xiàn)金送出。打印機打印回執(zhí)。輔事件流:如果取款金額不是100的整數(shù)倍，則顯示信息''輸入金額必須是100的整數(shù) 倍，請重新輸入”，并返回主事件流中步驟（l）o如果取款金額超過200

18、0元，則顯示信息“輸入金額不能超過2000元，請重 新輸入”，并返回主事件流中步驟（l）o如果賬戶余額小于取款金額，則顯示信息''賬戶余額不足，請重新輸入”， 并返回主事件流中步驟（1）。顧客在確認取款金額前可以選擇取消交易。后置條件:如果取款成功，系統(tǒng)從賬戶余額中減去相應數(shù)額，并返回等待狀態(tài)：如 果顧客取消交易，則返回等待狀態(tài)。4. 3概念模型和頂層架構設計（）4. 3.1概念模型設計從分析類所負責的主要功能需求看，系統(tǒng)可以包含三種分析類：1. 邊界類：負責目標軟件系統(tǒng)與參與者之間的交互，構造型為boundary。通常 情況下，參與者與用例之間的一種通信連接對應一個邊界類。貝

19、職責包括：2. 控制類：作為完成用例任務的責任承擔者，負責協(xié)調、控制其它類共同完成用例 規(guī)泄的功能或行為。構造型為control。用例通常對應控制類。3. 實體類：負責保存目標軟件系統(tǒng)中具有持久意義的信息項并向其它類提供讀、寫 信息項內(nèi)容的必要操作接口，一般不涉及業(yè)務邏借處理。構造型為«entity»。4. 3. 2頂層架構設計（目的）頂層架構的主要目的是為后續(xù)的分析和設計活動建立一種結構和劃分，以便開發(fā)人員 在不同的開發(fā)階段，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。4. 6. 2調整軟件構成類對類進行調整和優(yōu)化主要包括：1. 增加輔助類：2. 合并相互通

20、信頻繁的類：3. 分拆規(guī)模過大的類；第五章面向數(shù)據(jù)流的軟件設計方法5.2實體關系圖數(shù)據(jù)對象有屬性描述，通常，屬性包括：1. 命名性屬性：對數(shù)據(jù)對象的實例命名，苴中必含有一個或一組關鍵屬性，以便唯一地標 識數(shù)據(jù)對象的實例。2. 描述性屬性：對數(shù)據(jù)對象實例的性質進行描述。3. 引用性屬性：將自身與其他數(shù)據(jù)對象的實例關聯(lián)起來。規(guī)范化規(guī)則：1. 數(shù)據(jù)對象的任何實例對每個屬性必須有且僅有一個屬性值：2. 屬性是原子數(shù)據(jù)項，不能包含內(nèi)部數(shù)據(jù)結構；3. 如果數(shù)據(jù)對象的關鍵屬性多于一個,那么其他非關鍵屬性必須表示整個數(shù)據(jù)對象而不是部.分關鍵屬性的特征：5. 所有的非關鍵屬性必須表示整個對象而不是部分屬性的特征

21、。5.4面向數(shù)據(jù)流的設計過程（）5.4.1變換流與事務流而向數(shù)據(jù)流的方法能方便地將數(shù)據(jù)流圖轉換為軟件結構，其過程分為五部：1. 確定信息流的類型：2. 劃分流界：3. 將數(shù)據(jù)流圖映射為程序結構：4. 提取層次控制結構：5. 通過設計復審和使用啟發(fā)式策略進一步精化所得到的機構。5.4. 2變換分析步驟1：復審基本系統(tǒng)模型步驟2：復審和精化軟件數(shù)據(jù)流圖步驟3：確定數(shù)據(jù)流圖的特性，判定它為變換流還是事務流步驟4：通過劃定輸入流和輸出流的邊界來孤立變換中心，即把DFD劃分成邏輯輸入、主加 工和邏輯輸出三個部分。步驟5：執(zhí)行“一級分解”步驟6：執(zhí)行“二級分解”，即設計中下層模塊步驟7：采用啟發(fā)式設計策略

22、，精化所得程序結構雛形，以求改良軟件質量5. 4. 3事務分析步驟一：復審基本系統(tǒng)模型步驟二：復審并精化軟件數(shù)據(jù)流圖步驟三：確泄數(shù)據(jù)流圖的特性，判泄它為變換流還是事務流步驟四：指出事務中心，確定由事務中心發(fā)出的每一動作路徑的數(shù)拯流特性步驟五：把數(shù)據(jù)流圖映射為事務處理型的程序結構步驟六：分解并精化事務結構以及每條動作路徑所對應的結構步驟七：使用啟發(fā)式設訃策略，精化所得程序結構雛形，改良軟件質量例：針對圖所示的DFD,采用事務分析法導出程序結構，因其主體數(shù)據(jù)流為事務流（c為事務中 心）。顯然，區(qū)域I為變換流；區(qū)域II為事務流，但其各個子流為變換流：區(qū)域III為變換流。 在你所設計的程序結構中，除了

23、每個變換對應一個模塊外，可能還需增加若干控制模塊。組合得程序結構的雛形，精化雛形，如下圖:I n I I d IEOI SI B III 1 fgl h 控 11 El片2|I”3| 甲4| 向 nh 顧控31宙 filE 白 由mrhrVirni區(qū)3囚回回 帀同 111 ® 色E由吋由申四EK1 mCTIE1K由第六章用戶界面設計6.1界面設計的基本原則原則描述用戶熟悉程度界面應該采用經(jīng)常使用系統(tǒng)的用戶所熟悉的術語和概念一致性界面必須一致，在任何可能的情況下相同的操作應該以同樣的方式被激活使驚訝最小化盡量避免使用戶對系統(tǒng)的行為感到驚訝可恢復性界而應該為用戶提供錯誤恢復機制用戶幫助界

24、而應該在錯誤發(fā)生時提供有意義的反饋.并且提供上下文敏感的用戶幫 助系統(tǒng)用戶多樣性界而應該為不同類型的用戸提供恰當?shù)慕换シ绞?. 2設計良好界面的主要途徑用戶界而設汁中有三條“黃金規(guī)則”（如何理解）1使系統(tǒng)處于用戶控制之中2. 減少用戶記憶負擔3. 保持界而一致性6. 3. 2界面分析和設計模型在用戶界面的分析和設計過程中，有四種模型能夠起作用:1. 用戶模型2. 設計模型3. 心智模型或系統(tǒng)感知模型4. 實現(xiàn)模型6. 4用戶界面分析用戶分析技術；任務分析用戶采訪和問卷調査群體文化學6. 5.2界面設計需考慮的問題1. 響應時間系統(tǒng)響應時間有兩個重要特征：長度和變化性； 變化方式是指與平均響應時

25、間的偏差：2用戶幫助消息措辭中的設計因素閔素描述上下文用戶指南系統(tǒng)應該能注意到用戶為前在T什么，針對十耐上下文調機輸出信 息經(jīng)驗因為用戶逐漸變得對系統(tǒng)熟悉了，同時也會對兀過于詳細的消息所激 怒。但初學者可能還嫌太短，問.題闡述得不夠消遵。用戶指南系統(tǒng)應該提供兩種 類型信息并允許用戶控制消息的簡明程度技能水半消息應該根據(jù)用戶的技能和經(jīng)驗進行剪裁。消息應該根據(jù)不同類里的用戶對 彖選擇不同的農(nóng)達方式和所用的術語風格消息應該足枳極的而不足消極的。應該以主動方式去表示出來而不足被動顯 示。它們決不能足物理的或足滑梢怪誕的文化消息的設計諸應該盡可能地熟悉系統(tǒng)所銷倒的國家的文化傳統(tǒng)。在歐洲、亞 洲和關洲之間

26、存在右L1大的文化差亓。條消息對一個地區(qū)是適合的而在另個 地區(qū)就可能是不可接受的第七章軟件體系結構風格和設計模式7.1基本概念軟件設計模式：可解決一類問題并能重復使用的解決方案軟件體系結構風格:它是軟件設汁人員在長期的軟件設汁過程中總結岀來的一些規(guī)律性的東 西，經(jīng)過提煉總結而成。7. 2. IWright ADL構件連接件System ProcedureCail component Definer匚過程調用系統(tǒng)port provide ptwide protocol spec Definer protocol _ component Caller =port request requestpr

27、otocol spec Caller protocolcounecfor DOconnector =role de f iner = call 一 return 一 de finer § role culler = call 一 ret - caller n §_ glue = raller.call dcfincr.call 、glue de finer, ret ttm caller yfwn. glue粘連規(guī)范實例Iiisfnncesd: Definerc: Caller de: D-C-connectorAftaclimcnts聯(lián)接<1.provide ns

28、<lc.definer;c.request as de.caller end ProccckircCall.調用實例的Wright體系結構描述調用實例的GADL體系結構描述一構件圖調用實例的GADL體系結構描述一類圖 實例剖析：統(tǒng)計a. txt中單詞的個數(shù)并打印出來：shell命令："cat a. txt | wc | lpr"K cat命令輸出a. txt的內(nèi)容2、通過管道傳給命令wc,統(tǒng)計輸入流中單詞的個數(shù)并輸出3、輸出的單詞數(shù)通過管道傳給命令lpr, lpr將其打印出來一個“管道/過濾”系統(tǒng)實例:系統(tǒng)功能：讀取一個字符流，并輸出把每隔一個的字符轉換成大寫字母的字

29、符流。1. 管道/過濾器風格特征：系統(tǒng)中構件之間通過數(shù)據(jù)流松散耦合。也就是說，構件之間的依賴僅僅是數(shù)據(jù)流，而 不是通常的接口函數(shù)調用或消息傳遞。2. 分層風格特征：從向外提供服務的構件岀發(fā)，沿著連接關系遞次搜索各構件和連接件，如果形成的拓 撲結構是一個有向無圈圖（典型情況下是一個線性結構），那么這個系統(tǒng)的體系結構風格就 是層次式的。這種設訃風格便于將復雜的系統(tǒng)進行分解：同時也便于構件替換：只要保持接 口一致，就可以將某一層的軟件替換掉，而不會影響到系統(tǒng)的英他部分。7.4設計模式設計模式，并將它們分為三種類型：創(chuàng)建型設訃模式、結構型設汁模式和行為型設汁模式。1. Factory Method 例：“龍珠”游戲-設計1適用場合：有一些實體（各種魔力管道），它們的結構和行為是相似的，且都包含一些相似 的更小實體（各類球），但一個大實體內(nèi)部的這些小實體都是同一類的（一種魔力管道內(nèi)只 有一種球）。核心思想歸納：在父類中，將創(chuàng)建對象的操作包裝為一個虛函數(shù)，在描述公共行為的過程中 調用該函數(shù)：在子類中重泄義該虛函數(shù)來定制創(chuàng)建的對象，從而間接左制公共行為。利用虛 函數(shù)的多態(tài)機制，F(xiàn)actory Method模式使得父類可集中描述公共行為，而將特別行為（不 同對象的創(chuàng)建）抽放于子類。2. Abstract Factory 例：魔力管道。適用場合：當需要創(chuàng)建一組多種